KR101908341B1 - Data processor proceeding of accelerated synchronization between central processing unit and graphics processing unit - Google Patents

Abstract

A data processor according to an embodiment of the present invention includes a CPU (central processing unit) for processing a plurality of first data, a GPU (graphics processing unit) including a plurality of calculation units and a cache memory, A shared memory shared for storage,
Wherein each of the plurality of calculation units includes a plurality of threads, at least some of the plurality of calculation units operate as an activation thread group and the remainder of the plurality of calculation units operate as a deactivation thread group,
The active thread group converting the plurality of first data into a plurality of second data and causing the inactive thread group to process dummy data input and output so that the plurality of second data converted in the activation thread group and the inactive Wherein the plurality of second data stored in the cache memory is transferred to the shared memory by causing the dummy data processed in the thread group to fill the cache memory together to thereby perform an accelerated synchronization between the CPU and the GPU Processor.

Description

TECHNICAL FIELD [0001] The present invention relates to a data processor that performs synchronization by accelerating a synchronization between a CPU and a GPU.

The present invention relates to a data processor for performing synchronization by accelerating a synchronization between a CPU and a GPU, the data processor requesting data from a CPU to be processed in a GPU and then being transferred to a shared memory, .

Recently, many researchers have studied GPU (Graphics Processing Unit) to accelerate packet processing performed in network applications. Many of the achievements show that performance is further enhanced by the large memory bandwidth and the high-parallel computation capacity when the GPU is implemented concurrently with the CPU. However, recent research shows that, for many applications, the key to high performance is not the GPU's parallel computation capabilities, but the automatic hiding of memory access latency. It also claims that if the code is rearranged to hide the memory access latency using optimizations such as group prefetching or software pipelining, the CPU can perform similar or better than the GPU do.

In this patent, we review the recent research to see if it can be generalized to large-scale network applications. According to one embodiment of the present patent application, there are eight popular algorithms that are widely applicable to network applications, including: a) a computer-based algorithm that fails to optimize based on CPU but gains benefit from parallel processing capability by GPU , And b) the relative performance advantage of the CPU on behalf of the GPU is due to the data transfer bottleneck in the individual GPU's PCIe communication rather than the lack of capacity of the GPU itself. In order to avoid PCIe bottlenecks, this patent proposes that an APU platform with integrated CPU and GPU is used as a cost-effective packet processing accelerator. In addition, the patent solves a real problem in fully exploiting the capacity of the APU, and APU-based network applications can demonstrate achieving tens of Gbps performance for many computing / memory intensive algorithms.

This patent proposes that APU platform with integrated CPU and GPU is used as cost-effective packet processing accelerator. In addition, the patent solves a real problem in fully exploiting the capacity of the APU, and APU-based network applications can demonstrate achieving tens of Gbps performance for many computing / memory intensive algorithms.

 A data processor according to an embodiment of the present invention includes a CPU (central processing unit) for processing a plurality of first data, a GPU (graphics processing unit) including a plurality of calculation units and a cache memory, Wherein each of the plurality of calculation units includes a plurality of threads, at least some of the plurality of calculation units operate as an active thread group, and the remainder of the plurality of calculation units are inactive threads Wherein the active thread group converts the plurality of first data into a plurality of second data and causes the inactive thread group to process dummy data input and output, 2 data and the dummy data processed in the inactive thread group together with the cache memory By Li to fill, it is possible to ensure that the second data of the plurality stored in the cache memory is transferred to the shared memory to perform the speed synchronization between the CPU and the GPU.

In this patent, the CPU and GPU integrated APU platform can be used as a cost-effective packet processing accelerator. In addition, the patent solves a real problem in fully exploiting APU capacity, and APU-based network applications can achieve tens of Gbps performance for many computing / memory intensive algorithms.

1 is a block diagram of an embodiment of a typical external GPU in accordance with an embodiment of the invention.
2 is a block diagram illustrating data flow through a shared memory 300 between a CPU 100 and a GPU 200 constituting an acceleration processing unit (APU) according to an embodiment of the present invention.
3 and 4 are performance comparison charts of the algorithms evaluated in the CPU-based external / embedded GPU.
5 is a diagram of the overall architecture of APUNet according to one embodiment of the present invention.
6 is a diagram illustrating a configuration of a thread group that operates in any one of the control units 210-1 of the control units 210 of the GPU 200. [
7 is a graph of packet processing latency based on various packet sizes according to an embodiment.
8 is a graph showing transmission results by various packet sizes according to an embodiment.
9 is a graph showing the result of evaluating APUnet's network application.

The following detailed description of the invention refers to the accompanying drawings, which illustrate, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that the various embodiments of the present invention are different, but need not be mutually exclusive. For example, certain features, structures, and characteristics described herein may be implemented in other embodiments without departing from the spirit and scope of the invention in connection with an embodiment. It is also to be understood that the position or arrangement of the individual components within each disclosed embodiment may be varied without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is to be limited only by the appended claims, along with the full scope of equivalents to which such claims are entitled, if properly explained. In the drawings, like reference numerals refer to the same or similar functions throughout the several views.

Hereinafter, a data processor 1 that accelerates synchronization between a GPU 200 and a shared memory 300 according to an embodiment of the present invention will be described with reference to the accompanying drawings.

PUs are widely used to accelerate computing and memory intensive applications. With hundreds or thousands of processing cores and large memory bandwidth, the GPU has the potential to improve the performance of parallelizable applications. Fortunately, many network applications are categorized into categories that make them suitable for the GPU's execution model. In fact, many studies have shown that the GPU is helping to improve the performance of network applications.

In recent years, however, the relative performance of a GPU on behalf of a CPU to accelerate network applications has been questioned. Recent achievements show that most of the gain from the GPU is based on fast hardware thread switching that transparently hides memory access latency instead of its high computational power. In addition, applying group prefetching optimization techniques and software pipelining to the CPU code shows that it is more resource-efficient than the GPU-accelerated version for many networking applications.

This patent re-examines the recent work on the GPU's effectiveness in accelerating network applications. Through in-depth experiments and inferences, the following observations can be made in the present invention. For the first time, we have found that the computational power of the GPU is important in improving the performance of many computing-intensive algorithms widely used in network applications. According to the present invention, the popular encryption algorithms of SSL and IPSec, such as RSA, SHA-1 / SHA-2 and ChaCha20, can show the benefits of parallel computation cycles rather than transparent memory access time concealment. They exceed the performance of optimized CPU code from 1.3 to 4.8 times (x). Second, CPU-based code optimization techniques such as G-Opt [32] improve the performance of pure CPU code, while its acceleration power is limited compared to GPU performance without CPU-GPU data transfer overhead . By cost per performance metric, it can be seen that GPUs are 3.1x (x) to 4.8x (x) more cost effective if the GPU avoids the CPU-GPU data transfer overhead. Third, it can be seen that according to the present invention, the main bottleneck in GPU operation is due to the overhead of data transfer between the CPU and the GPU caused by PCIe communication instead of the lack of capacity in the GPU device itself. However, since individual packet processing generally does not require much computation or memory access, it can be difficult to hide the delay in transferring data between the CPU and the GPU. This can make it difficult to transfer asynchronous data (for example, simultaneous copying and execution of the GPU kernel) to fully overlap with GPU kernel execution. It is not surprising that, in GPU-accelerated network applications, PCIe data transfer limits performance benefits because PCIe bandwidth is typically much smaller than the GPU's memory bandwidth. In order to maximize the advantages of the GPU without the overhead of data transfer between the CPU and the GPU, the present invention can use an Accelerated Processing Unit (APU) in which the CPU and the GPU are integrated to accelerate the network applications. APU provides a single, unified memory space for both CPU and GPU, eliminating the overhead of data transfer between the CPU and the GPU, making it attractive for packet processing. In addition, it can be a cost-effective accelerator for networked systems because the power consumption is very low (eg $ 35 to $ 350 for AMD Carrizo) at a low price (eg $ 100 to $ 150). So how we implement a high-performance packet processing engine is key.

However, achieving high performance in APU based packet processing is a bit of a real challenge. First, in contrast to external GPUs, the built-in GPUs have to share the memory with the (DRAM) CPU, losing the benefit of high-bandwidth GDDR memory in the external GPU. Because both the CPU and the GPU share a shared memory bus and controller, it is important to use memory bandwidth efficiently for high performance. Second, the communication overhead between the CPU and the GPU, which switches contexts and synchronizes data updates, takes up most of the GPU run time. Unlike an external GPU, this overhead is no longer blocked by the overlapped GPU kernel execution. Also, because the CPU and GPU use separate caches, the cache coherency of the APUs must be done through expensive operations. This means that the results processed by the GPU are not easily visible on the CPU without atomics synchronization or a slow GPU kernel termination.

This patent attempts to implement this challenge through a system called APUNet (High Performance APU Accelerated Network Packet Processor). For an effective implementation of memory bandwidth, APUNet can make extensive use of zero-copying at all stages of packet processing (packet reception and processing by the CPU and GPU). In this patent, this broad zero-copying model helps to extract more advanced computational power from integrated GPUs and outperforms 4.2 times (x) -5.4 times (x) in the IPsec standard . ≪ / RTI > To minimize communication between the CPU and the GPU, the APUNet can adopt a persistent GPU kernel run that keeps the thread of the GPU running in parallel in the continuous input packet stream untimely. Combining with zero copy to eliminate GPU kernel startup and shutdown can reduce the packet processing latency by as much as 8.2 times (x) from 7.3 times (x), and the waiting time to collect the batch of packets for parallel execution . APUNet can also perform "group synchronization" in which GPU threads implicitly bulk synchronize memory areas of processed packets to avoid heavy atomics instructions. After the group synchronization, the CPU checks the result of the updated packet in the GPU (e.g., non-zero values in the HMAC digest), thereby effectively ensuring consistent data access between the CPU and the GPU, Can be improved by 5.7 times.

APUNet can achieve high speed and cost effective network packet processing on several popular network applications. According to the patent, all network applications, except for IPv4 forwarding, can outperform the CPU baseline with optimal implementation, regardless of memory or computational power. APUNet can improve CPU performance by 1.6 times in IPv6 forwarding, 2.2 times in IPsec gateway, 2.8 times in SSL proxy, and 4.0 times in NIDS.

External GPU (Discrete GPU)

Part of the GPU-accelerated network systems have used an external GPU (discrete GPU) to improve the performance of network applications. A typical external GPU takes the form of a PCIe peripheral device that communicates with the host side via a PCIe lane, as shown in FIG. It can be composed of separate GDDR memories with thousands of processing cores (eg 2048 on NVIDIA GTX980) and a large memory bandwidth (eg 224 GB / s for GTX980). It can adopt a single-instruction multiple-thread (SIMT), and under SIMT, a group of threads (NVIDIA's warp or wavefront of AND hardware) is the same in a lock-step manner Simultaneously execute the instruction stream. Multiple warps (eg, 4 in GTX980) can be used to share thousands of registers for fast context switch switching between caches (instruction, L1, shared memory) or for fast command / data access It runs on a streaming multiprocessor (SM). SMs are mostly optimized for instruction-level parallelism, but they do not implement sophisticated branch prediction or speculative execution that are commonly available in modern CPUs. While all threads can achieve high performance when executing the same basic block in parallel, the execution of another thread in the warp is fully serialized when one thread leaves the instruction stream due to a branch.

Due to primitive computation cycles and memory bandwidth, a typical external GPU can outperform the CPU's work capabilities. For example, the NVIDIA GTX980 has 110 times the computation cycles and 3.8 times the memory bandwidth of the Intel Xeon E5-2650 v2 CPU. Such large computational power brings obvious performance benefits to massively parallel workloads or deep neural networks such as supercomputing. However, within other workloads that do not have enough parallelism, the GPU will perform poorly because it can not drive the hardware sufficiently. Thus, since this patent focuses on packet processing in network applications, we can ask if the GPU has better performance than the CPU in popular network applications.

Integrated GPU (Integrated GPU)

In recent years, the built-in GPU has gained more popularity with increasing computing power. Unlike an external GPU, the built-in GPU is manufactured in the same die as the CPU, which shares memory (DRAM) with the CPU. Intel and AMD have a lineup of embedded GPUs (such as AMD's Accelerated Processing Unit (APU) or Intel HD Graphics) that can be programmed into OpenCL. Figure 2 shows an example of an architecture of an embedded GPU in an AMD Carrizo APU. 2, the data processor 1 according to an embodiment of the present invention may be an APU and the data processor 1 may include a CPU 100, a GPU 200, a shared memory 300, DRAM), an interface unit 400, and a memory controller 500. The GPU 200 may include a plurality of calculation units 210-1, 210-2, .., 210-8 and a cache memory 220. [

The PU 100 may process a plurality of first data, and may include one master and a plurality of workers as shown in FIG. The plurality of first data may be packet data.

Each of the plurality of calculation units 210-1, 210-2, ..., 210-8 included in the PU 200 as shown in FIG. 2 may include a plurality of threads as shown in FIG. These plurality of threads may form a group, act as an active thread group, or act as an inactive thread group. The thread group of FIG. 6 is an example of an activation thread group, wherein the activation thread may include an active thread and an idle thread. Here, the separate processing of the effective thread and the idle thread will be described later.

At this time, the active thread group may convert the plurality of first data of the CPU 100 into a plurality of second data, and the inactive thread group may process the dummy data input / output.

The plurality of second data converted in the active thread group and the dummy data processed in the inactive thread group together fill the cache memory 200 so that a plurality of second data stored in the cache memory 200 is stored in the shared memory 300 to perform accelerated synchronization between the CPU 100 and the GPU 200.

The interface unit 400 may include, for example, a north bridge and an integrated north bridge. The interface unit 400 receives a plurality of second data from the GPU 200 and transmits the second data to the memory controller 500, A plurality of second data received from the interface unit 400 can be transmitted to the shared memory 300. [

A typical embedded GPU has a smaller number of processing cores and has a lower computational capacity than an external GPU. For example, AMD Carrizo has eight calculation units (CUs) each containing 64 streaming cores (512 cores in total). The L2 cache, which is a cache memory according to an embodiment of the present invention, is used as a synchronization point across computing units (CUs), while the L1 cache and registers are shared within the streaming cores on the CU.

Despite less computing power, built-in GPUs are still considered attractive platforms due to much lower power consumption (eg, 35W for AMD Carrizo) and lower prices (eg, $ 100- $ 150) compared to external GPUs. Later, the built-in GPU can show that it is the most cost-effective accelerator of performance per price.

The most notable aspect of the embedded GPU is that it shares the same memory subsystem with the CPU. On the positive side, it allows efficient data sharing between CPU and GPU. Conversely, an external GPU must perform expensive CPU-to-GPU memory data transfers on PCIe, which is defined as the main bottleneck for processing. For efficient memory sharing, OpenCL supports shared virtual memory (SVM), which represents the same virtual address space for CPUs and GPUs. Shared virtual memory (SVM) allows buffer pointers to be exchanged between the CPU and the GPU, potentially eliminating the memory transfer (copying) to share data. On the negative side, on the other hand, shared memory significantly increases the overhead on the memory controller and reduces the usable memory bandwidth per processor. To alleviate this problem, the integrated GPU uses a separate L1 / L2 cache, but it poses another issue of cache coherency. Cache coherency between the CPU and the GPU can be done through OpenCL's atomics instructions. However, direct synchronization can result in large overloads. In the present patent, the above-mentioned two issues will be described later. First, with extended zero-copying from packet acceptance for GPU processing, the CPU and GPU share efficient memory bandwidth for packet processing. Second, we use a technique that implicitly synchronizes the result data in the embedded GPU cache to the shared memory so that the processing results on the GPU can be delivered to the CPU with low overhead.

- Reference algorithm: Evaluated algorithms

There are algorithms such as IP forwarding table lookup, Multi-string pattern matching, ChaCha20-Poly1305, SHA-1 / SHA-2, and RSA algorithms in CPU-based (baseline and optimized CPU) and external / embedded GPU. The performance comparison tables for these are shown in FIG. 3 and FIG.

-APUNet Design and Implementation

In this patent, an implementation for an APU-accelerated network packet processing system (APU) called APUNet is described. For high performance, APUNet uses the CPU for scalable packet I / O, while the embedded GPU is used for parallel packet processing. Once we have described the practical problems of using the APU, we want to describe a solution for it.

- Challenges and achievements

APU enables efficient data sharing between the CPU and the GPU, but there is a real problem to achieve high performance. First, sharing of memory (DRAM) brings overhead on the memory controller and bus, potentially reducing the effective memory bandwidth for each processor. Since many packet processing tasks are memory intensive and packet I / O itself consumes memory bandwidth, memory bandwidth can be one of the core resources of network applications. This patent attempts to reduce memory bandwidth overhead by a wide range of zero-copy packet processing that eliminates unnecessary data copying between the CPU and the GPU, as well as between the network card (NIC) and application buffers. Second, it can be seen that frequent GPU kernel launch and teardown result in overhead in packet processing. This is because the GPU will initialize the context registers when the GPU kernel launches in the APU and will execute the instructions to synchronize the results to the shared memory shared with the CPU side during teardown. In order to solve this problem, it is assumed that the GPU kernel start / end is eliminated through continuous thread execution. A persistent GPU thread execution only launches the kernel once and continues to process the packet in a loop without termination. However, the APU can not guarantee cache coherency between the CPU and the GPU, each with its own cache, and has the problem of requiring costly atomics operations to synchronize the data in the cache of the two processors. This patent attempts to overcome this problem with group synchronization, in which cache data is implicitly exported to the shared memory only when data sharing from cache to memory is required. This can also significantly reduce the cost of synchronization.

- Overall system architecture

5 is a diagram of an overall architecture of an APUNet according to an embodiment of the present invention. As shown in FIG. 5, the APUNet according to an embodiment of the present invention may include a CPU 100, a GPU 200, and a shared memory 300 '(for example, a virtual shared memory). The CPU 100 may include one master and a plurality of worker frames. When the worker performs packet I / O and requests packet processing with the GPU through the master, the master can communicate directly with the GPU. The master and each worker can be implemented as threads fixed to one of the CPU cores. The CPU and GPU can share a packet memory pool that stores packet pointer arrays and packet payloads. They can also share application-specific data structures such as IP forwarding tables or key values for cryptographic operations.

The present invention describes how a packet is processed in APUNet. APUNet uses the Intel DPDK packet I / O library to collect incoming packets in batches. Each worker processes some of the packets that are load balanced using receive-side scaling (RSS). When batch packets arrive at the worker thread, the worker thread checks each packet for validity and puts packet pointers into the master's data queue. The master then notifies the GPU of the arrival of new packets, and GPU threads that are continuously running within the GPU perform packet processing, respectively. When the packet processing is complete, the GPU synchronizes these results to the master thread. The master then notifies the worker of the result in the worker's result queue, and the worker thread finally sends the processed packets to the network port. Details of the data synchronization will be described in detail below.

- Continuous GPU thread execution

GPU-based packet processing typically collects a large number of packets for high utilization of GPU threads. However, such a model involves two drawbacks. First, it increases the packet processing delay time due to waiting while collecting packets. Second, each GPU kernel launch and teardown results in an overhead that further delays the processing time of the next batch of packets. Overhead is an important issue in APU because each GPU kernel has to synchronize updated data between CPU and GPU at launch and teardown.

To solve this problem, the present invention uses a persistent GPU kernel execution method. Basically, it keeps the running of many GPU threads processing the input packet stream continuously and without end. This approach avoids the overhead of kernel launch and teardown and reduces packet processing latency by allowing them to process newly arriving packets directly. However, this naive implementation may cause many threads to execute different paths each time a new packet arrives in the same command stream, which may prevent the GPU's parallel processing from being used properly.

APUNet tries to find the right balance between packet batching and parallel processing for efficient and coherent thread execution. To this end, it is necessary to understand how APU hardware works. Each calculation unit (CU) of the GPU has four SIMT units, and each SIMT unit consists of 16 work items (or threads) for processing the same instruction stream in parallel. Thus, in the present invention, the packets are put into the GPU in multiples of the SIMT unit so that all the threads are executed in parallel simultaneously. The master dequeues packets into a number of SIMT units in the data queue, groups them, and delivers them to the GPU in batches. For example, you can implement a batch of 32 packets and the threads parallelize the packets within the two SIMT units (GPU thread group size). If the number of dequeue packets from the master queue is less than the GPU thread group size, the GPU threads that have no packets to process within the group remain idle. In this way, if the next batch of packets arrive, they are processed by a separate GPU thread group. In accordance with one embodiment of the present invention, transferring new packets to a separate GPU thread group may yield better results than transmitting to idle GPU threads within an activated GPU thread group.

According to an embodiment of the present invention, a plurality of second data converted from a plurality of first data of the CPU 100 is stored in the GPU 200, and a plurality of second data is transferred to the shared memory 300 , And may be performed by accelerating synchronization between the GPU and the shared memory. The first data according to an embodiment of the present invention may include data generated and processed by the CPU 100 and transmitted to the GPU 200, and the second data may include dirty data items .

For example, when a GPU receives data from a CPU and the received data is processed and converted to dirty data items, the converted dirty data items are first stored in the GPU. In addition, the dirty data items may be transferred to the shared memory 300 through a group-based implicit flush so that the synchronization between the CPU 100 and the GPU 200 through the shared memory 300 may be accelerated .

According to one embodiment of the present invention, the GPU 200 includes thread groups, the thread groups operate as active threads that are active or deactivated inactive threads, and a plurality of second data stored in the GPU 200 are active Thread may be sent to the shared memory 300 via the thread.

According to Fig. 6, the overall architecture of coherent threading is shown. The CPU and the GPU share a per-group state that identifies the mode of the GPU thread group, such as active (non-zero) and break (idle, ex> zero) This status value indicates the number of packets to be processed by each GPU thread group. All GPU thread groups are initialized to a break state and are continuously polled until they are activated. When new packets arrive, the master thread activates the group by locating the GPU thread group at rest and setting it to a state value that allows packet processing. When a GPU thread group detects a non-zero state, each GPU thread in the group compares its local ID with its state value to determine whether there is a packet to process .

GPU threads whose local ID is less than the status value start to find and process the packet pointer array indexed by its global ID in the packet pointer array. And other threads remain idle waiting on the memory barrier. For example, as shown in FIG. 6, when the state value is 28, threads 0 through 27 smaller than 28 are classified as valid threads, and threads 28 through 31 are classified as idle threads. When all threads in this group have finished executing and encounter these barriers, the thread with the local ID of the minimum value changes the group status back to 0 to inform the CPU that the packet processing is finished. 5, the CPU 100 may include one master and a plurality of workers. As a result of the master included in the CPU 100 periodically monitoring the state of the GPU 200, If it is determined that all of the plurality of threads included in the activated thread group have been processed, the master can transmit the determination result to the plurality of workers.

- Group synchronization

Another issue with persistent GPU threads is how to guarantee cache coherency between the CPU and the GPU at low cost. When the GPU finishes packet processing, its results are not easily seen on the CPU. This is because the results stay in the GPU's L2 cache, which is the synchronization point of the GPU thread, not the shared memory that the CPU can see. To directly synchronize GPU updates to shared memory, OpenCL provides atomics instructions along with the C ++ 11 standard. The atomix operation is performed through a coherent work path as indicated by the dotted arrow in Fig. Where the work can be performed by a coherent hub (CHUB) located in the graphics north bridge. Unfortunately, they are expensive to require additional commands such as locking, and CHUB can only perform one atomic operation at a time. All atomics operations result in overhead, and serial processing of requests from thousands of GPU threads results in significant overhead and overall performance degradation.

To solve this problem, group synchronization can be performed. It allows the GPU thread group to implicitly synchronize the memory areas of the processed packets. For intrinsic synchronization, the present invention may utilize a GPU LRU (Least Recently Used) cache replacement policy for exporting dirty data items in the GPU cache to the shared memory.

For example, when a plurality of data received from a CPU is sequentially converted from a GPU to a dirty data item, the sequentially converted dirty data items may be sequentially transferred to the shared memory. That is, the dirty data item of the first converted GPU can be sequentially transferred to the shared memory. According to an embodiment of the present invention, it is possible to use resting GPU thread groups with a current state value of zero so that they can perform dummy data I / O in separate distinct memory blocks, This data can fill the capacity of the L2 cache so that the resultant data of the packet that was previously stored in the L2 cache can be exported to the shared memory. This brings additional overhead to memory, but it can be seen that it is more efficient to intrinsically synchronize the memory area of the group than to synchronize every packet through the Atomix command.

Idle threads in an active GPU thread group (for example, a thread with a local ID greater than its group state value) are allowed to perform dummy data I / O from the instruction stream of activated threads To serialize the work, it is still waiting on the memory barrier, which results in parallel processing of the packet processing. If all GPU thread groups are active, all GPU threads will store the results in the GPU's cache so that dirty data in the cache will be exported to shared memory without dummy data I / O. Finally, data validation between the CPU and the GPU can be assured by the CPU verifying that the packet processing results have been updated.

- Packet processing latency

7 is a diagram of packet processing latencies based on various packet sizes according to an embodiment.

- APUNet synchronization experiment result

We will evaluate the performance improvement of group synchronization compared with the above-mentioned atomics. To this end, the present invention executes a test for passing 64B IP packets to the GPU driving the IPsec kernel code. Since the IPsec module can completely update the IP payload during encryption, the present invention selects the IPsec module as the default GPU kernel. As a result, the overall packet result of the GPU needs to be synchronized to the shared memory that the CPU sees. Zero copy packet processing and continuous thread execution are implemented by default. Through the measurements, we found that group synchronization with APUNet results in a performance increase of 5.7 times compared to synchronizing with the atomics method. In the present invention, it has been found that APUNet can achieve high performance at low cost by reducing the overhead in synchronization between the CPU and the GPU.

The present invention determines the practicality of the APUNet in real network applications by comparing the CPU baseline output with the G-Opt optimized implementations.

- IPv4 / IPv6 packet forwarding

In the present invention, a network application for transmitting an IPv4 / IPv6 packet to a random destination IP address is implemented. APUNet then performs IPv4 / IPv6 table lookups and then sends packets to the appropriate network port. For the IPv6 table lookup, we evaluated the lookup algorithm based on hashing with an algorithm based on longest prefix matching (LPM). Figure 8 shows the transmission results by various packet sizes. In the present invention, it can be seen that G-Opt efficiently hides the memory access of the IPv4 / IPv6 table lookups, thereby improving the performance based on the CPU baseline from 1.25 times to 2.0 times. Unfortunately, in APUNet, the transmission by IPv4 as shown in Fig. 8 (a) may be degraded for various reasons. First, IPv4 table lookup is a simple operation, and the communication overhead between the CPU and the GPU accounts for a relatively large portion of the total packet processing time. Second, APUNet monopolizes one master CPU core to communicate with the GPU, and only three CPU cores perform packet I / O, which is insufficient to satisfy the advanced performance of the four CPU cores of IPv4 . Also, there is a performance penalty when using the SVM to use a shared packet memory pool between the CPU and the GPU. On the other hand, IPv6 forwarding as shown in FIG. 8 (b) requires more complicated operations. APUNet can outperform 1.6 times the optimized CPU implementation (G-Opt) for hashing-based IPv6 forwarding. Here, IPv6 forwarding based on LPM is resource efficient because it does not require hashing, so we can see that the performance of APUNet is similar to that of G-Opt.

- IPsec gateway

We will describe how efficiently APUNet runs network applications through the IPsec gateway. The IPsec gateway encrypts the packet payload of the 128-bit AES scheme in CBC mode and generates an authentication digest with HMAC-SHA1. The CPU baseline and G-Opt versions can use Intel's AES-NI, an x86 instruction set that drives each AES encryption / decryption with a single AESENC / AESDEC instruction. APUNet can implement the GPU version of IPsec gateway by combining AES-CBC and HMAC-SHA1 kernel code into one integrated kernel for continuous GPU thread execution. Fig. 9 shows the results of the evaluation. Since AES is already optimized with hardware instructions and HMAC-SHA1 instructions are computationally intensive, G-Opt fails to improve CPU baseline performance. APUNet, on the other hand, shows a 2.2x speed-up improvement and achieves 16.4 Gbps throughput at 1451B packet size.

- Network instruction detection system (NIDS)

We want to apply NIDS to APUNet. APUNet based NIDS is Aho-Corasick

(AC) pattern match algorithm to scan incoming network traffic for known attack signatures. In the present invention, we have ported NIDS using a Snort-based attack rule set that monitors malicious activity on the network and applies G-Opt to the AC pattern matching code. Figure 10 shows the processing results for randomized payloads and harmless synthetic traffic with various packet sizes. Here, full NIDS does not benefit from G-Opt. This allows access to numerous data structures (packet acquisition, decoding and detection modules) of the NIDS during packet analysis and by causing overloading of the data cache such that prefetched data can be accessed by other prefetches before they are used Resulting in the removal of already cached data. On the other hand, APUNet helps boost performance by up to 4 times compared to CPU-based NIDS for large packet sizes. For small packet sizes, APUNet is inefficient because of low computational load (only 10B of payload is scanned in 64B packets), similar to IPv4 forwarding

The features, structures, effects and the like described in the embodiments are included in one embodiment of the present invention and are not necessarily limited to only one embodiment. Furthermore, the features, structures, effects and the like illustrated in the embodiments can be combined and modified by other persons skilled in the art to which the embodiments belong. Therefore, it should be understood that the present invention is not limited to these combinations and modifications.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is clearly understood that the same is by way of illustration and example only and is not to be taken by way of illustration, It can be seen that various modifications and applications are possible. For example, each component specifically shown in the embodiments can be modified and implemented. It is to be understood that all changes and modifications that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

Claims (6)

A CPU (central processing unit) for processing a plurality of first data;
A GPU (graphics processing unit) including a plurality of calculation units and a cache memory; And
And a shared memory shared by the CPU and the GPU for data storage,
Wherein each of the plurality of calculation units includes a plurality of threads, at least some of the plurality of calculation units operate as an activation thread group and the remainder of the plurality of calculation units operate as a deactivation thread group,
Said activation thread group converting said plurality of first data into a plurality of second data,
Allowing the inactive thread group to process dummy data input / output,
The plurality of second data converted in the activation thread group and the dummy data processed in the inactive thread group together fill the cache memory so that the plurality of second data stored in the cache memory is transferred to the shared memory And perform accelerated synchronization between the CPU and the GPU.
The method according to claim 1,
An interface unit; And
Further comprising a memory controller,
And the memory controller transfers the plurality of second data received from the interface unit to the shared memory.
3. The method according to claim 1 or 2,
Wherein the first data is packet data.
The method according to claim 1,
The plurality of threads each including an identifier identifying the plurality of threads,
Wherein the plurality of threads are processed based on a state value indicating a state of a thread that can be processed by the GPU,
If the identifier is a thread smaller than the status value, the thread transforms the plurality of first data as the effective thread into the plurality of second data,
And if the identifier is a thread with a status value equal to or greater than the status value, the thread remains in the first memory barrier as an idle thread.
5. The method of claim 4,
Wherein the activation thread group is initialized by a thread having a minimum identifier of the plurality of threads when all of the plurality of threads included in the activation thread group are processed and reach a second memory barrier.
The method according to claim 1,
Wherein the CPU comprises a master exclusively communicating with the GPU and a plurality of walkers performing data input / output via the master,
When the master included in the CPU periodically monitors the state of the GPU and determines that all of the plurality of threads included in the activation thread group have been processed, the master notifies the determination result to the plurality of walkers Lt; / RTI >

Images