Accelerator offload device, accelerator offload method, and program

Abstract

An accelerator offloading device (1) comprises: a device pseudo-function unit (201) that enqueues a request in a reception queue corresponding to an application (10); a transfer queue determination unit (203) that determines an enqueueing destination for the request stored in the reception queue; reception queues (202) which are provided respectively in correspondence to a plurality of applications and which enqueue requests in transfer queues; a transfer queue selection unit (205) that gives, to each transfer queue, a dequeue instruction to prioritize the dequeuing of a high-priority transfer queue according to predetermined transfer queue selection logic; and transfer queues (204) that follow the dequeue instruction and output requests to a device queue (51) of an accelerator (5).

Description

Technical Field

[0001] The present invention relates to an accelerator offloading device, an accelerator offloading method, and a program.

Background Art

[0002] Depending on the type of processor, the workload that the processor is good at (has high processing power) is different. For a highly versatile CPU (Central Processing Unit), there are accelerators such as FPGA (Field Programmable Gate Array) / (in the following description, " / " represents "or") GPU (Graphics Processing Unit) / ASIC (Application Specific Integrated Circuit) that can perform operations on a workload with a high degree of parallelism that the CPU is not good at (has low processing power) quickly and efficiently. (Hereinafter, these are appropriately referred to as ACCs). By combining these different types of processors and offloading the workload that the CPU is not good at to the ACC for operation, the utilization of offloading technology to improve the overall operation time and operation efficiency has been progressing.

[0003] In vRAN (virtual Radio Access Network) etc., when the performance of only the CPU is insufficient to meet the requirements, some processing is offloaded to a high-speed operable accelerator such as an FPGA or a GPU.

[0004] In the look-aside type of offloading, as shown in FIG. 23, a thread of the application (APL) 10 sends a request to the accelerator 5 provided in the HW (hardware) 53 through the packet processing API, and receives the response after the processing in either the polling mode (a method of looping the read function for the device) or the interrupt mode (a method in which the read function is issued契机にtriggered by a hardware interrupt from the device). The accelerator resources to be sent and received by the thread are fixedly allocated in units such as the device queue 51 at the initialization of the application 10. Also, the accelerator 5 processes the requests from the respective threads in a round-robin manner from the device queue 51 that has received the requests (see Non-Patent Document 1).

Prior Art Documents

Non-Patent Documents

[0005]

Non-Patent Document 1

Non-Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0006] There are cases where multiple applications are installed on the same server, each with different performance requirements. For example, vRAN has both the highly reliable and low-latency URLLC (Ultra-Reliable and Low Latency) profile and the ultra-high-speed, high-capacity eMBB (enhanced Mobile Broadband) profile, with URLLC having stricter latency requirements.

[0007] As shown in Figure 24, for example, by offloading the requirements of URLLC and eMBB to multiple accelerators 5, it may be possible to achieve the requirements without them interfering with each other. In Figure 24, in an example where the URLLC performance requirements are required for APL1 and the eMBB performance requirements are required for APL2, the application 10 corresponding to each of the two accelerators 5 is shown to be processed. However, since the number of power-hungry accelerators 5 increases (to two in this case), power consumption cannot be reduced.

[0008] On the other hand, as shown in Figure 25, by using a technology (see Non-Patent Literature 2) that provides acceleration resources to each application 10 individually through virtual function units (VFs) of the accelerator 5, the number of accelerators 5 can be reduced and power consumption can be lowered. In Figure 25, two VFs 55 (VF1, VF2) are provided on one accelerator 5 to process applications 10 (APL1, APL2). However, since the accelerator 5 is shared, the load on the other application 10 may affect the performance of each application 10.

[0009] When multiple applications 10 are connected to the same accelerator 5 via VF55, it is common for the accelerator 5 to process requests from each VF55 with the same priority without processing them separately. Therefore, requests from multiple VF55s are treated equally, and the throughput of one application 10 may be limited by the load of the other application 10, or the latency may increase due to the load of the other application 10.

[0010] Figure 26 shows the total throughput according to the load for APL1, which requires high reliability and low latency URLLC performance requirements, and APL2, which requires ultra-high speed and high capacity eMBB performance requirements. In Figure 26, the horizontal axis of both figures, indicated by reference numerals 81 and 82, shows the load of APL2 when the load of APL1 is constant, and the vertical axis shows the total throughput of APL1 and APL2. In the conventional technology, as shown in the diagram labeled 81 in Figure 26, when the load on APL2 increases, the throughput of APL1 is affected by the load on APL2 because requests from both VF55 (Figure 25) are treated equally (labeled a in the diagram labeled 81). Ideally, however, as shown in the diagram labeled 82 in Figure 26, it is desirable that the throughput of APL1, which has stringent performance requirements, remains constant regardless of the load on APL2 (labeled b in the diagram labeled 82).

[0011] Figure 27 shows the delay time of APL1 when the load of APL2 increases, while the load of APL1 is kept constant. In Figure 27, the horizontal axis of both figures, indicated by reference numerals 83 and 84, represents the load of APL2, and the vertical axis represents the delay time of APL1. The load of APL1 is assumed to be constant. In the conventional technology, as shown in the figure labeled 83, when the load on APL2 increases, the delay time of APL1 also increases; in other words, APL1 is affected by the load on APL2 (symbol c in the figure labeled 83). Ideally, as shown in the figure labeled 84, it is desirable that the delay time of APL1, which has strict performance requirements, remains constant beyond a predetermined value even when the load on APL2 increases (symbol d in the figure labeled 84).

[0012] Thus, with conventional technology, the performance value of one application 10 is affected by the load of the other application 10 offloaded to the same accelerator 5, resulting in the problem that the performance requirements set for application 10 cannot be met.

[0013] In light of this background, the present invention was made, and its objective is to prevent the performance degradation of applications that occurs when the power consumption of an accelerator is reduced, and to reduce the power consumption of the accelerator. [Means for solving the problem]

[0014] The accelerator offload device according to the present invention is an accelerator offload device having an accelerator that offloads the processing of multiple applications with different performance requirements to the accelerator, and includes a device pseudo-function unit that receives requests from the applications and enqueues the requests in an acceptance queue corresponding to the applications, while appearing to communicate with the accelerator by realizing an interface function equivalent to that of the accelerator, and acquires metadata attached to the received requests and stores a transfer queue corresponding to a basic priority indicating the priority of the application according to the performance requirements in the acceptance queue for each request. The system is characterized by comprising: a transfer queue determination unit that determines the destination for enqueuing the requested request; an acceptance queue provided for each of the multiple applications, which buffers the request and enqueues the request to the transfer queue determined by the transfer queue determination unit; a transfer queue selection unit that, according to the priority associated with each of the transfer queues, issues a dequeuing instruction to each of the transfer queues to prioritize dequeuing the transfer queue with the highest priority using a predetermined transfer queue selection logic; and a transfer queue provided for each priority, which buffers the request and outputs the request to the accelerator's device queue in accordance with the dequeuing instruction. [Effects of the Invention]

[0015] According to the present invention, it is possible to prevent the performance degradation of applications that occurs when the power consumption of the accelerator is reduced, and to reduce the power consumption of the accelerator. [Brief explanation of the drawing]

[0016] [Figure 1] This is a functional block diagram showing the overall configuration of the accelerator off-road device according to this embodiment. [Figure 2] This figure shows an example of the data structure of the reception queue information according to this embodiment. [Figure 3] This figure shows an example of the data structure of the transfer queue determination information according to this embodiment. [Figure 4] This is a diagram showing an example of the data configuration of transfer queue information according to this embodiment. [Figure 5] This is a diagram showing an example of the data configuration of transfer queue selection information according to this embodiment. [Figure 6] This is a diagram for explaining the outline of the processing request order control executed by the accelerator offload device according to this embodiment. [Figure 7] This is a diagram for explaining the outline of the throughput control executed by the accelerator offload device according to this embodiment. [Figure 8] This is a diagram showing an example of the data configuration of application performance information according to this embodiment. [Figure 9] This is a diagram for explaining an example in which the transfer queue selection unit determines the risk to the performance of high-priority applications based on the delay time and changes the transfer queue selection logic. [Figure 10] This is a diagram for explaining an example in which the queue upper limit determination unit determines the risk to the performance of high-priority applications based on the delay time and changes the queue upper limit. [Figure 11] This is a diagram showing an example in which the real-time discriminator changes the priority according to the time budget for each request. [Figure 12] This is a diagram showing an example in which the bandwidth reservation unit reserves an empty transfer queue for high priority in advance. [Figure 13] This is a sequence diagram showing the flow of the processing (forward path) executed by the accelerator offload device according to this embodiment. [Figure 14] This is a sequence diagram showing the flow of the processing (return path) executed by the accelerator offload device according to this embodiment. [Figure 15] This is a flowchart showing the flow of the transfer queue determination process executed by the accelerator offload device according to this embodiment. [Figure 16] This is a flowchart showing the flow of the priority determination process based on the time budget according to the time slot. [Figure 17] This is a diagram for explaining an example of the time slot. [Figure 18] This flowchart shows the flow of the transfer queue selection process using weighted round-robin. [Figure 19] This flowchart shows the process of selecting a transfer queue based on priority. [Figure 20] This flowchart shows the queue limit determination process executed by the accelerator offload device according to this embodiment. [Figure 21] This flowchart shows the flow of the queue selection ratio determination process performed by the accelerator offload device according to this embodiment. [Figure 22] This is a hardware configuration diagram showing an example of a computer that implements the functions of the accelerator offload device according to this embodiment. [Figure 23] This figure shows a conventional example where an accelerator is installed in the hardware to offload application processing. [Figure 24] This diagram illustrates an example of offloading the processing of multiple applications with different performance requirements to multiple accelerators. [Figure 25] This diagram illustrates an example of offloading the processing of multiple applications with different performance requirements to a single accelerator via multiple VFs. [Figure 26] This figure shows the total throughput according to the load of APL1, which requires URLLC performance requirements, and APL2, which requires eMBB performance requirements. [Figure 27] This figure shows the delay time of APL1 when the load of APL2 increases, while the load of APL1 remains constant. [Modes for carrying out the invention]

[0017] Hereinafter, with reference to the drawings, the accelerator off-road device 1, etc., in an embodiment for carrying out the present invention (hereinafter referred to as "this embodiment") will be described.

[0018] Figure 1 is a functional block diagram showing the overall configuration of the accelerator off-road device 1 according to this embodiment. The accelerator offload device 1 aims to control the amount of resources used by the accelerator 5 for each application 10 when multiple applications 10 offload processing to the installed accelerator 5 ACC 5. In this case, the accelerator off-road device 1 shall satisfy the following requirements.

[0019] (Requirement 1) Application transparency The ability to use accelerator resources without requiring the addition of special features to control resource usage within the application. (Requirement 2) Eliminate performance impact on high-priority applications The ability to exclude performance impacts from other application processes based on application priority. (Requirement 3) Eliminate accelerator dependency No additional functionality is required to control resource usage on the accelerator side.

[0020] The accelerator offload device 1 according to this embodiment aims to reduce the power consumption of the accelerator without affecting the performance of other applications, even when there are multiple applications on the same server with different performance requirements, by satisfying the above requirements (1) to (3), while eliminating the need for additional functions on the application side and accelerator side (requirements 1 and 3). In particular, with respect to requirement 2, it aims to reduce the power consumption of the accelerator without affecting the performance of other applications, even when there are multiple applications on the same server with different performance requirements. Therefore, the accelerator offload device 1 does not employ methods where the application prioritizes and orders requests before passing them to the accelerator, nor does it employ methods where the accelerator prioritizes and orders requests for each application. Instead, it employs a method (using a proxy) where a proxy placed between the application and the physical device prioritizes and orders requests for each application obtained through a packet processing API (Application Programming Interface) before passing them to the accelerator. The details of the accelerator offload device 1 are described below.

[0021] As shown in Figure 1, the accelerator offload device 1 comprises an application 10 having multiple APL1 and APL2, a packet processing unit 20, an offload management unit 30, and a hardware 50. Here, APL1 is a high-priority application 10 that requires, for example, highly reliable and low-latency URLLC performance requirements, and offloading from accelerator 5 is achieved by thread #1. On the other hand, APL2 is a low-priority application 10 that requires, for example, ultra-high-speed, high-capacity eMBB performance requirements, and offloading from accelerator 5 is achieved by thread #2.

[0022] The HW50 includes physical devices such as the Accelerator (ACC) 5, as well as a CPU and NIC (physical NIC) which are not shown in the diagram. Accelerator 5 is a computing unit hardware that performs specific calculations at high speed based on input from the CPU. Examples of accelerator 5 include FPGA (Field Programmable Gate Array) and ASIC (Application Specific Integrated Circuit). In Figure 1, accelerator 5 is assumed to have one IP core (Intellectual Property Core) 52 and a device queue 51 that holds data in a first-in, first-out list structure. Note that, as shown in Figure 1, accelerator 5 may have a virtual functional unit (VF55) of the accelerator described above to process data from applications (APL1, APL2), or it may process data without providing VF55.

[0023] The packet processing unit 20 is a set of functions that mediate when offloading packet processing to the accelerator 5. Specifically, the packet processing unit 20 is data high-speed transfer middleware located in user space, and is composed of, for example, DPDK (Data Plane Development Kit). This packet processing unit 20 includes a device pseudo-function unit 201, an acceptance queue 202, a transfer queue determination unit 203, a transfer queue 204, a transfer queue selection unit 205, a physical device transfer unit 206, a performance acquisition unit 207, and a real-time performance determination unit 208.

[0024] The device pseudo-function unit 201 implements interface functions equivalent to those on the HW50 side, making it appear as if APL1 and APL2 (application 10) are communicating with the accelerator 5. Because of this device pseudo-function unit 201, application 10 only needs to perform the same processing as if it were communicating directly with the accelerator 5, thus satisfying the transparency to the application described in (Requirement 1) above. In other words, it eliminates the need to add any special functions to application 10. Then, when this device pseudo-function unit 201 receives a request from each thread (thread #1, thread #2) of each application 10 (APL1, APL2), it enqueues the request to the reception queue 202 (adds the data to the end of the queue).

[0025] When the device pseudo-function unit 201 receives a request, it obtains the APL_ID corresponding to the thread that sent the request. The device pseudo-function unit 201 also obtains the metadata attached to the request. Then, based on the APL_ID, the device pseudo-function unit 201 refers to the reception queue information 210 shown in Figure 2 and stores the request in the reception queue 202 provided in association with each application (APL1, APL2).

[0026] Figure 2 shows an example of the data structure of the reception queue information 210 according to this embodiment. As shown in Figure 2, the reception queue information 210 stores the reception queue ID of the reception queue 202, which is associated with the APL_ID of each application 10. Figure 2 shows an example in which four reception queues are provided, corresponding to four applications 10. This reception queue information 210 is pre-configured information and is stored in a storage unit of the accelerator offload device 1, which is not shown in the illustration.

[0027] When the device pseudo-function unit 201 receives a request, it refers to the reception queue information 210 and enqueues the request in the reception queue 202 with the reception queue ID corresponding to the APL_ID. Furthermore, the device pseudo-function unit 201 outputs the acquired metadata to the transfer queue determination unit 203 in order to perform priority control on a request-by-request basis.

[0028] A reception queue 202 is provided for each application 10 and buffers requests from each application (for example, APL1, APL2). Then, the reception queue 202 enqueues the request to the appropriate priority transfer queue 204, as instructed by the transfer queue determination unit 203.

[0029] The transfer queue determination unit 203 determines the transfer queue 204 to which requests to be dequeued (data retrieved from the top of the queue) from the reception queue 202 will be enqueued, according to the priority of the request. At that time, the transfer queue determination unit 203 refers to the transfer queue determination information 220 shown in Figure 3, for example, to obtain the transfer queue ID corresponding to the reception queue ID of the reception queue 202 to be dequeued, and enqueues the request to the transfer queue 204 indicated by that transfer queue ID.

[0030] Figure 3 shows an example of the data structure of the transfer queue determination information 220 according to this embodiment. As shown in Figure 3, the transfer queue determination information 220 stores the transfer queue ID corresponding to the reception queue ID. Figure 3 shows an example in which four transfer queues 204 corresponding to four priority levels are provided. This transfer queue determination information 220 is stored in a storage unit that is not shown in the figure.

[0031] Furthermore, the transfer queue determination unit 203 determines whether the metadata of the request received from the device pseudo-function unit 201 contains information that allows for priority determination (priority information). If priority information (for example, information indicating that it is urgent traffic, as described later) is included, the transfer queue determination unit 203 determines a transfer queue 204 with a priority corresponding to that priority information as the enqueue destination (details are described later).

[0032] Furthermore, even if the metadata does not contain priority information, the transfer queue determination unit 203, if it is possible to obtain time budget information for each request, determines the priority using the real-time determination unit 208 (described later), and determines the transfer queue 204 to which each request will be enqueued according to the determined priority (details are described later).

[0033] The forwarding queue 204 is set up according to the priority of each request and buffers the requests received from the reception queue 202. Furthermore, when buffering requests, the transfer queue 204 refers to the transfer queue information 230 shown in Figure 4. If the number of requests that can be enqueued exceeds the upper limit (queue limit), it stops enqueuing requests from the reception queue 202 because it cannot enqueue any more requests.

[0034] Figure 4 shows an example of the data structure of the transfer queue information 230 according to this embodiment. As shown in Figure 4, the transfer queue information 230 stores information such as priority, queue limit, and current number of queued items, associated with the transfer queue ID of each transfer queue 204. Priority indicates the degree of priority of the requests stored in the transfer queue 204. In the example in Figure 4, priorities "1" to "4" are assigned to each transfer queue 204. Here, priority "1" is the highest priority, and priority "4" is the lowest priority. The queue limit is information indicating the upper limit of the number of requests that the transfer queue 204 can enqueue, and is determined by the queue limit determination unit 302, which will be described later. The current queue count indicates the number of requests currently buffered in the transfer queue 204. This transfer queue information 230 is stored in a storage unit, which is not shown in the diagram.

[0035] The transfer queue 204 dequeues the request and outputs it to the physical device transfer unit 206, in accordance with the instructions of the transfer queue selection unit 205, which will be described later.

[0036] The transfer queue selection unit 205 instructs the dequeueing of each transfer queue 204 according to the priority of each transfer queue 204, using predetermined logic (transfer queue selection logic). For example, the transfer queue selection unit 205 outputs a dequeue command to each transfer queue 204 according to a pre-set queue selection ratio (weighted round robin) corresponding to the priority of each transfer queue 204. At that time, the transfer queue selection unit 205 refers to the transfer queue selection information 240 shown in Figure 5 to determine the selection ratio for dequeuing from each transfer queue 204.

[0037] Figure 5 shows an example of the data structure of the transfer queue selection information 240 according to this embodiment. As shown in Figure 5, the transfer queue selection information 240 stores the ratio (read ratio) of requests to be read from each transfer queue 204, associated with the transfer queue ID of each transfer queue 204. This transfer queue selection information 240 is stored in a storage unit that is not shown in the figure.

[0038] The transfer queue selection unit 205 uses the information on the delay performance value (delay time) for each application 10 acquired by the performance acquisition unit 207 (described later), and the information based on the number of requests pending in the accelerator 5 acquired from the device status acquisition unit 301 (described later), to calculate a queue selection ratio that does not affect the performance of high-priority applications. Then, the transfer queue selection unit 205 updates the queue selection ratio (read ratio) in the transfer queue selection information 240 (Figure 5) based on the calculation result.

[0039] The physical device transfer unit 206 receives a request from the transfer queue 204 and enqueues the request to the device queue 51 of the accelerator 5.

[0040] <<Processing Request Order Control>> Here, an overview of the processing request sequence control performed by the accelerator offload device 1 will be explained with reference to Figure 6.

[0041] When the device pseudo-function unit 201 receives requests from threads #1 and #2 of each application 10 (APL1 and APL2), the device pseudo-function unit 201 refers to the transfer queue determination information 220 and enqueues the requests to the reception queue 202 corresponding to each application 10 (APL1 and APL2) of threads #1 and #2 (step S10).

[0042] Next, the reception queue 202 selects the corresponding transfer queue 204 for the request according to the priority determined by the transfer queue determination unit 203 (step S11), and enqueues the request.

[0043] Based on a predetermined logic (transfer queue selection logic) set in the transfer queue selection unit 205, the transfer queue 204 enqueues the request to the device queue 51 in such a way that many dequeues are performed from the high-priority queues (step S12).

[0044] In this way, the accelerator offload device 1 can satisfy requirement 2, elimination of performance impacts, by controlling the processing order of the accelerator 5 according to the priority of the requests.

[0045] <<Processing volume control>> Next, an overview of the processing volume control performed by the accelerator offload device 1 will be explained with reference to Figure 7. Here, steps S10 and S11 are the same as the processes shown in Figure 6, so they are denoted by the same reference numerals and their explanations are omitted.

[0046] When the transfer queue 204 buffers a request from the reception queue 202, it refers to the transfer queue information 230 (Figure 4), and if buffering the request would exceed the queue limit, it stops enqueuing requests from the reception queue 202 (step S21).

[0047] Next, the transfer queue 204 enqueues requests from each transfer queue 204 to the device queue based on a predetermined logic (transfer queue selection logic) set in the transfer queue selection unit 205 (step S22).

[0048] In this way, the accelerator offload device 1 can perform processing volume control according to the priority of requests, thereby prioritizing the transfer queue of high-priority requests and transferring them to the accelerator 5, thus satisfying (Requirement 2) Elimination of performance impacts.

[0049] Returning to Figure 1, the performance acquisition unit 207 acquires the performance delay value (delay time) for each application 10 from the request and response interval between the application 10 and the accelerator 5. The performance acquisition unit 207 then outputs this performance delay value (delay time) to the transfer queue selection unit 205, the queue upper limit determination unit 302, and the real-time performance determination unit 208. The transfer queue selection unit 205 and the queue upper limit determination unit 302 determine whether the acquired performance delay value (delay time) exceeds predetermined thresholds (upper threshold, lower threshold) by referring to the application performance information 250 shown in Figure 8.

[0050] Figure 8 shows an example of the data structure of the application performance information 250 according to this embodiment. As shown in Figure 8, the application performance information 250 stores information such as the basic priority, upper threshold, lower threshold, and current performance, associated with the APL_ID of the application 10.

[0051] The base priority is the fundamental priority corresponding to the application 10, and any settable priority is pre-assigned to the transfer queue information 230 (Figure 4). The upper limit threshold is a threshold used to determine whether or not to change the parameters of the transfer queue selection logic or queue limit in order to prevent the performance of high-priority application 10 from being affected when the latency time becomes large. The lower threshold is the threshold used to determine whether to terminate the parameter change and revert to the original value after the delay time has become too large and the parameter change has been made. Current performance is the performance delay value (delay time) of application 10 at the present time, as acquired by the performance acquisition unit 207. This application performance information 250 is stored in a memory unit, which is not shown in the diagram.

[0052] Figure 9 illustrates an example in which the transfer queue selection unit 205 determines the risk to the performance impact of a high-priority application (APL1) based on the delay time and modifies the transfer queue selection logic. Between times t0 and t1, the transfer queue selection unit 205 instructs dequeuing of high-priority and low-priority transfer queues in a selection ratio of "2:1". At time t1, if the delay time of APL1 obtained from the performance acquisition unit 207 exceeds the upper threshold, the transfer queue selection unit 205 changes the transfer queue selection logic to change the selection ratio of high-priority and low-priority transfer queues to "4:1". Then, at time t2, if the delay time of APL1 falls below the lower threshold, the transfer queue selection unit 205 changes the transfer queue selection logic to return the selection ratio of high-priority and low-priority transfer queues to "2:1".

[0053] In this way, the accelerator offload device 1 can increase the processing of high-priority applications by changing the parameters of the transfer queue selection logic when the delay time increases, thereby satisfying (Requirement 2) Elimination of Performance Impacts.

[0054] Figure 10 illustrates an example in which the queue limit determination unit 302 determines the risk to the performance impact of a high-priority application (APL1) based on the delay time and changes the queue limit. Assume that between time t0 and t1, the queue limit determination unit 302 has set the same queue limit (e.g., "100") for both the high-priority and low-priority transfer queues in the transfer queue information 230 (Figure 4). Here, at time t1, if the delay time of APL1 obtained from the performance acquisition unit 207 exceeds the upper limit threshold, the queue limit determination unit 302 reduces the queue limit of the transfer queue 204 corresponding to the low-priority application (e.g., "30"). Then, at time t2, if the delay time of APL1 becomes less than the lower limit threshold, the queue limit determination unit 302 restores the queue limit of the transfer queue 204 corresponding to the low-priority application (e.g., "100").

[0055] In this way, when the delay time increases, the accelerator offload device 1 can increase the processing of high-priority applications by changing (reducing) the queue limit of the transfer queue corresponding to low-priority applications, thereby satisfying (Requirement 2) Elimination of Performance Impacts.

[0056] Returning to Figure 1, the real-time determination unit 208 calculates the time budget remaining for the request based on the configured time slot if the metadata obtained from the request does not include priority information. The real-time determination unit 208 then outputs information to the transfer queue determination unit 203 indicating that requests with a small time budget should be processed first and enqueued in a high-priority transfer queue.

[0057] For example, as shown in Figure 11, even if a request is stored in the reception queue 202 corresponding to thread #2 of application 10, APL2, which is a low-priority application, if the time budget of that request is small, the real-time determination unit 208 outputs information to that effect to the transfer queue determination unit 203, thereby controlling the request to be distributed to the high-priority transfer queue 204. The priority determination process of this real-time determination unit 208 will be described later with reference to Figures 16 and 17.

[0058] In this way, the accelerator offload device 1 can satisfy requirement 2, elimination of performance impacts, by distributing requests with low time budgets to the high-priority transfer queue 204.

[0059] Returning to Figure 1, the offload management unit 30 controls the offload processing of requests based on information from HW50 (accelerator 5) and the external controller 7. The offload management unit 30 includes a device status acquisition unit 301, a queue limit determination unit 302, and a bandwidth reservation unit 303. The offload management unit 30 may be provided inside the accelerator offload device 1, as shown in Figure 1, or it may be provided in a separate device and communicate with the packet processing unit 20 of the accelerator offload device 1 to send and receive information.

[0060] The device status acquisition unit 301 counts the number of requests pending on the accelerator 5. The device status acquisition unit 301 then outputs the counted number of requests pending on the accelerator 5 to the transfer queue selection unit 205 and the queue limit determination unit 302. Furthermore, the device status acquisition unit 301 may predict future delay times based on the number of pending requests counted by the accelerator 5, and output the predicted delay time to the transfer queue selection unit 205 and the queue limit determination unit 302.

[0061] The transfer queue selection unit 205 and the queue limit determination unit 302, having obtained information on the number of requests (or predicted delay time) pending in the accelerator 5 from the device status acquisition unit 301, refer to the application performance information 250 (Figure 8), etc., and determine whether the number of pending requests (or delay time) exceeds a predetermined threshold (upper threshold, lower threshold). When the device status acquisition unit 301 outputs the number of requests pending on the accelerator 5 to the transfer queue selection unit 205 and the queue upper limit determination unit 302, information on the upper and lower thresholds corresponding to the number of pending requests is stored in a storage unit (not shown in the figure).

[0062] If the number of pending requests (or the predicted delay time) exceeds a predetermined threshold (upper threshold, lower threshold), the transfer queue selection unit 205 executes the same process as the transfer queue selection logic modification process shown in Figure 9. Furthermore, if the number of pending requests (or the predicted delay time) exceeds a predetermined threshold (upper threshold, lower threshold), the queue limit determination unit 302 performs the same processing as the queue limit change processing shown in Figure 10.

[0063] The queue limit determination unit 302 determines the queue limit for requests to be stored in each transfer queue 204 and sets it in the transfer queue information 230 (Figure 4). As described above, the queue limit determination unit 302 obtains performance delay value (delay time) information from the performance acquisition unit 207 and information on the number of requests (or predicted delay time) pending in the accelerator 5 from the device status acquisition unit 301, determines whether it exceeds a predetermined threshold (upper threshold, lower threshold), and changes the queue limit information set in the transfer queue information 230 (Figure 4).

[0064] When the bandwidth reservation unit 303 obtains historical traffic data or prediction information that a burst of the highest priority requests will be sent via an external controller 7 (for example, a RIC (RAN Intelligent Controller)), it outputs an instruction to the transfer queue determination unit 203 to stop enqueuing to the high-priority transfer queue 204 in advance and to empty the queue.

[0065] For example, as shown in Figure 12, if it is predicted that the number of requests from thread #0 will increase in a burst-like manner at time t1, the bandwidth reservation unit 303 instructs the transfer queue determination unit 203 to keep the high-priority transfer queue free at a predetermined time Δt before time t1. Upon receiving this instruction, the transfer queue determination unit 203 changes the destination of the requests stored in the acceptance queue 202 of thread #1 from the high-priority transfer queue 204 to the low-priority transfer queue 204, thereby keeping the high-priority transfer queue 204 empty at time t1.

[0066] In this way, the accelerator offload device 1 can minimize request delays when bursts of requests occur, thereby satisfying requirement 2) elimination of performance impacts.

[0067] <Processing of the accelerator off-road device> Next, we will explain the processes performed by the accelerator offload device 1. First, the request flow from application 10 to accelerator 5's device queue 51 (outbound) executed by accelerator offload device 1 will be explained with reference to Figure 13, and the response flow from accelerator 5's device queue 51 to application 10 (return) will be explained with reference to Figure 14.

[0068] Figure 13 is a sequence diagram showing the flow of processing (forward journey) performed by the accelerator offload device 1. First, the device pseudo-function unit 201 receives a request from the application 10 thread (step S101).

[0069] The device pseudo-function unit 201 enqueues the received request in the application's reception queue 202 (step S102). The device pseudo-function unit 201 also stores the time the request was enqueued (transmission time) for delay time measurement. Specifically, the device pseudo-function unit 201 obtains the APL_ID corresponding to the thread that sent the received request, and, referring to the reception queue information 210 (Figure 2), enqueues the request in the reception queue 202 with the reception queue ID corresponding to the APL_ID. Furthermore, the device pseudo-function unit 201 outputs metadata obtained from the received request to the transfer queue determination unit 203 (step S103).

[0070] When the transfer queue determination unit 203 obtains metadata, it determines the transfer queue 204 to which the requests to be dequeued from the reception queue 202 will be enqueued, according to the priority of the requests (step S104). Furthermore, if priority information is included in the acquired metadata, the transfer queue determination unit 203 uses that priority information to determine the priority. Also, if priority information is not included in the acquired metadata, and the time budget (buffer time) remaining for the request can be calculated based on the set time slot, the transfer queue determination unit 203 outputs the information of the request to the real-time determination unit 208 to obtain information on whether or not it should be enqueued in the higher priority transfer queue 204 (step S104a).

[0071] If priority information is not present in the metadata, the transfer queue determination unit 203 refers to the transfer queue determination information 220 (Figure 3) to obtain the transfer queue ID corresponding to the reception queue ID, and determines the transfer queue 204 indicated by that transfer queue ID as the transfer queue 204 to which the request will be enqueued. In other words, it determines the enqueuing destination to the transfer queue 204 with the basic priority set for application 10. Furthermore, if the metadata contains priority information, the transfer queue determination unit 203 determines the transfer queue 204 to be the enqueuing destination according to that priority. In addition, if the transfer queue determination unit 203 obtains information from the real-time determination unit 208 that the request should be enqueued to a high-priority transfer queue 204 due to a low time budget, it determines the enqueuing destination for the request to be a transfer queue 204 with a higher priority than the basic priority. Details of the transfer queue determination process will be described later, referring to Figure 15. Furthermore, details of the process for determining priority based on the time slot buffer time (time budget) will be described later, referring to Figure 16.

[0072] The transfer queue determination unit 203 outputs information about the transfer queue 204 that will be the enqueuing destination for the request to the reception queue 202 (step S105).

[0073] When the reception queue 202 obtains information about the transfer queue 204 to which the request will be enqueued, it outputs the request to the transfer queue 204 with the determined priority (step S106).

[0074] The transfer queue 204 buffers requests received from the reception queue 202. In doing so, the transfer queue 204 refers to the transfer queue information 230 (Figure 4), and if the number of requests exceeds the queue limit set for the transfer queue 204, it cannot enqueue the request and stops enqueuing from the reception queue 202. Further details regarding the process for determining the queue limit will be described later, referencing Figure 20.

[0075] Next, the transfer queue selection unit 205 instructs the dequeueing of each transfer queue 204 according to predetermined logic (transfer queue selection logic) (step S107). The transfer queue selection logic will be described later, referring to Figures 18 and 19. Then, the transfer queue 204, having received the dequeue instruction, outputs the request to the physical device transfer unit 206 (step S108).

[0076] When the physical device transfer unit 206 receives a request from the transfer queue 204, it enqueues the request to the device queue 51 of the accelerator 5 (step S109).

[0077] Next, we will explain the response flow (return path) from the accelerator 5's device queue 51 to the application 10, which is executed by the accelerator offload device 1. Figure 14 is a sequence diagram showing the flow of processing (return trip) performed by the accelerator offload device 1.

[0078] First, the physical device transfer unit 206 obtains a response to the request from the device queue 51 of the accelerator 5 (step S201). The physical device transfer unit 206 then outputs the response to the device pseudo-function unit 201 (step S202).

[0079] The device pseudo-function unit 201 outputs the transmission time stored in step S102 of Figure 13 and the time the response was obtained (reception time) to the performance acquisition unit 207 (step S203). Then, the performance acquisition unit 207 calculates the delay time based on the difference between the time the request is sent and the time the response is received (step S204). The performance acquisition unit 207 outputs the calculated delay time information to the queue upper limit determination unit 302, the transfer queue selection unit 205, and the real-time performance determination unit 208 (steps S205a, S205b, S205c).

[0080] Furthermore, the device pseudo-function unit 201 sends the acquired response to the thread of application 10 (step S206).

[0081] ≪Transfer Queue Determination Process≫ Next, we will explain in detail the transfer queue determination process, which is mainly performed by the transfer queue determination unit 203. Figure 15 is a flowchart showing the flow of the transfer queue determination process executed by the accelerator offload device 1 according to this embodiment.

[0082] First, the transfer queue determination unit 203 obtains metadata attached to the request from the device pseudo-function unit 201 and determines whether or not the metadata of the request contains information that can determine the priority (priority information) (step S301). In this context, "including priority information" refers to cases where, for example, priority levels such as high priority or low priority are pre-assigned to the request as metadata.

[0083] If the request includes priority information (step S301 → Yes), the transfer queue determination unit 203 tentatively determines a transfer queue according to the priority of the request (step S302).

[0084] On the other hand, if the request does not contain priority information (step S301 → No), the transfer queue determination unit 203 determines whether it is possible to predict the priority based on the time slot buffer time (time budget) (step S303). If the transfer queue determination unit 203 determines that it is possible to predict the priority based on the time slot buffer time (step S303 → Yes), it outputs the metadata of the request to the real-time determination unit 208 and proceeds to step S304.

[0085] In step S304, the real-time determination unit 208 provisionally determines the priority and transfer queue based on the buffer time (time budget) corresponding to the time slot. Details of the priority determination process by this real-time determination unit 208 will be described later with reference to Figure 16.

[0086] On the other hand, if it is determined that it is not possible to predict the priority based on the time slot (step S303 → No), the transfer queue determination unit 203 obtains a transfer queue corresponding to the basic priority of the APL_ID corresponding to the reception queue 202 by referring to the transfer queue determination information 220 (Figure 3), and provisionally determines that transfer queue 204 (step S305).

[0087] In steps S302, S304, and S305, once the transfer queue 204 is tentatively determined, the transfer queue determination unit 203 determines whether or not the transfer queue 204 has been reserved by the bandwidth reservation unit 303 to become available (step S306). Then, if the transfer queue determination unit 203 is reserved (step S306 → Yes), it provisionally determines a transfer queue 204 with a priority one level lower than the provisionally reserved transfer queue 204 (step S307), and returns to step S306.

[0088] On the other hand, if the transfer queue 204 is not reserved in step S306 (step S306 → No), the transfer queue determination unit 203 determines the transfer queue 204 as the enqueue destination for the request (step S308) and ends the process.

[0089] <<Priority determination process based on time budget according to time slot>> Figure 16 is a flowchart illustrating the priority determination process based on the time budget corresponding to the time slot. Figure 17 is a diagram illustrating an example of a time slot. The real-time performance determination unit 208, in the case of a system where requests are sent in fixed time slots, such as vRAN, takes into account the delay time acquired by the performance acquisition unit 207 and determines the priority based on the remaining time budget (buffer time), even if there is no priority information in the request metadata.

[0090] The real-time determination unit 208 obtains request metadata from the transfer queue determination unit 203 and identifies the type of request (step S401). The real-time determination unit 208 then determines whether the type of request is emergency traffic (step S402). Here, emergency traffic refers to traffic that should be processed with the highest priority, such as error handling, as predetermined.

[0091] If it is determined that the traffic is urgent (step S402 → Yes), the real-time determination unit 208 sets the request to the highest priority (step S414). On the other hand, if it is determined that it is not an emergency traffic situation (step S402 → No), proceed to step S403.

[0092] In step S403, the real-time determination unit 208 obtains the start time t0 and end time t3 of the time slot #Tn corresponding to request #n. Figure 17 shows the time slot #Tn used by request #n. Processing must be completed between the start time t0 and end time t3 of this time slot #Tn (refer to Figure 17 as needed below).

[0093] Next, the real-time determination unit 208 obtains the current time t1 (step S404). Then, a performance value P corresponding to the application 10, which is the type of request, is obtained (step S405). Here, the performance value P is the delay time calculated by the performance acquisition unit 207.

[0094] Next, the real-time determination unit 208 calculates the predicted response completion time t2 using the following equation (1) (step S406). t2=t1+P...Formula (1)

[0095] Then, the real-time determination unit 208 calculates the buffer time B using the following equation (2) (step S407). B=t3-t2...Equation (2)

[0096] Next, the real-time determination unit 208 determines whether the basic priority of the request is equal to or higher than a predetermined priority (step S408). Here, if it is not equal to or higher than the predetermined priority (step S408 → No), the process proceeds to step S415 and the priority is not changed. This is to exclude changing the priority for low-priority requests that are not equal to or higher than the predetermined priority because there is no need to change requests originally allowed with a low priority to a high priority. On the other hand, if it is equal to or higher than the predetermined priority (step S408 → Yes), the process proceeds to step S409.

[0097] In step S409, the real-time determination unit 208 compares the buffer time B with the buffer time B2 with a margin (the second buffer time threshold) and determines whether it corresponds to B > B2 and the current priority (basic priority) is not the minimum. This means that when the buffer time B is larger than the buffer time B2 with a margin, there is a margin in the processing time. Therefore, if it corresponds to B > B2 and the current priority is not the minimum (step S409 → Yes), the priority is lowered by one from the current priority (basic priority) (step S410). On the other hand, if it does not correspond to B > B2 and the current priority is not the minimum (step S409 → No), the process proceeds to step S411.

[0098] In step S411, the real-time determination unit 208 compares the buffer time B with the buffer time B1 without a margin (the first buffer time threshold: a predetermined time threshold) and determines whether it corresponds to 0 < B < B1 and the current priority is not the maximum. This means that when the buffer time B is smaller compared to the buffer time B1 without a margin, there is no margin in the processing time. Therefore, if it corresponds to 0 < B < B1 and the current priority is not the maximum (step S411 → Yes), the priority is raised by one from the current priority (basic priority) (step S412). On the other hand, if it does not meet the condition of 0 < B < B1 and the current priority is not the maximum (step S411 → No), the process proceeds to step S413.

[0099] In step S413, the real-time determination unit 208 determines whether it meets the condition of B < 0 and the current priority is not the maximum. This means that since the buffer time is a negative value, the request to be prioritized needs to be set to the highest priority. Therefore, if it meets the condition of B < 0 and the current priority is not the maximum (step S413 → Yes), the current priority (basic priority) is set to the highest priority (step S414). On the other hand, if it does not meet the condition of B < 0 and the current priority is not the maximum (step S413 → No), the process ends without changing the priority (step S415).

[0100] In this way, even when there is no priority information in the request metadata, the real-time determination unit 208 can determine the priority by predicting the buffer time (time budget).

[0101] ≪Transfer Queue Selection Process≫ Next, the transfer queue selection process executed by the transfer queue selection unit 205 will be described. The transfer queue selection process is executed based on a predetermined logic (transfer queue selection logic) set in the transfer queue selection unit 205. As the transfer queue selection logic, weighted round robin (Figure 18) or priority order (Figure 19) is adopted.

[0102] Figure 18 is a flowchart showing the flow of the transfer queue selection process by weighted round robin. First, the transfer queue selection unit 205 selects the transfer queue 204 with the highest priority (highest priority) (step S501). Next, the transfer queue selection unit 205 refers to the transfer queue selection information 240 (Figure 5) and reads out the corresponding number of reads (read count) for the transfer queue 204 (step S502). In other words, the transfer queue selection unit 205 sends dequeue instructions for the number of reads (read count) to the transfer queue 204.

[0103] Next, the transfer queue selection unit 205 determines whether or not there is a transfer queue 204 with a lower priority than the transfer queue in question (step S503). If there is no transfer queue 204 with a lower priority than the transfer queue in question (step S503 → No), the process returns to step S501. On the other hand, if there is a transfer queue 204 with a lower priority than the transfer queue in question (step S503 → Yes), the transfer queue selection unit 205 selects the transfer queue 204 with the next highest priority (step S504) and returns to step S502.

[0104] In this way, the transfer queue selection unit 205 can dequeue requests from each priority transfer queue 204 based on the read ratio set in the transfer queue selection information 240 (Figure 5).

[0105] Figure 19 is a flowchart showing the flow of the transfer queue selection process based on priority. First, the transfer queue selection unit 205 selects the transfer queue 204 with the highest priority (highest priority) (step S601).

[0106] Next, the transfer queue selection unit 205 determines whether or not there is a request in the transfer queue 204 (step S602). If there is a request (step S602 → Yes), the process proceeds to step S603. In step S603, the transfer queue selection unit 205 issues a dequeue command to the transfer queue 204 to read all requests from the transfer queue 204. Then, the process returns to step S601.

[0107] On the other hand, if there is no request in step S602 (step S602 → No), the transfer queue selection unit 205 selects the next priority transfer queue 204 (step S604) and returns to step S602.

[0108] By doing so, the transfer queue selection unit 205 can prioritize the transfer queue 204 with the highest priority and dequeue requests from each transfer queue 204 of their respective priority levels.

[0109] ≪Queue Limit Determination Process≫ Next, we will explain the queue limit determination process executed by the queue limit determination unit 302, etc. Figure 20 is a flowchart showing the queue limit determination process executed by the accelerator offload device 1 according to this embodiment.

[0110] First, the performance acquisition unit 207 obtains the delay time for each application 10 from the request and response interval between the application 10 and the accelerator 5 (step S701). The performance acquisition unit 207 then outputs the acquired delay time to the queue upper limit determination unit 302.

[0111] Next, the device status acquisition unit 301 acquires the device status by counting the number of requests pending on the accelerator 5 (step S702). The device status acquisition unit 301 then acquires the number of pending requests (or the delay time predicted from the number of requests) and outputs it to the queue limit determination unit 302.

[0112] The queue limit determination unit 302 refers to the application performance information 250 (Figure 8) and the upper limit threshold information corresponding to the number of pending requests stored in the memory unit, and determines whether the delay time exceeds the upper limit threshold, or whether the number of pending requests (or the predicted delay time) exceeds the upper limit threshold (step S703).

[0113] The queue limit determination unit 302, if either of the transfer queues exceeds the upper limit threshold (step S703 → Yes), lowers the queue limit of the transfer queue 204 with a lower priority than the transfer queue 204 in question by a predetermined number (step S704).

[0114] On the other hand, if the queue limit determination unit 302 determines in step S703 that neither the delay time nor the number of pending requests (or the predicted delay time) exceeds the upper limit threshold (step S703 → No), it proceeds to step S705.

[0115] In step S705, the queue limit determination unit 302 refers to the application performance information 250 (Figure 8) and the lower threshold information corresponding to the number of pending requests stored in the memory unit, and determines whether the delay time is less than the lower threshold, or whether the number of pending requests (or the predicted delay time) is less than the lower threshold.

[0116] Then, if either of them is below the lower threshold (step S705 → Yes), the queue limit determination unit 302 increases the queue limit of transfer queues 204 with lower priority than the transfer queue 204 in question by a predetermined number (step S706).

[0117] On the other hand, in step S705, the queue limit determination unit 302 terminates processing without changing the queue limit if neither the delay time nor the number of pending requests (or the predicted delay time) is below the lower threshold (step S705 → No).

[0118] ≪Queue Selection Ratio Determination Process≫ Next, we will explain the queue selection ratio determination process performed by the transfer queue selection unit 205 and the like. Figure 21 is a flowchart showing the flow of the queue selection ratio determination process executed by the accelerator offload device 1 according to this embodiment.

[0119] First, the performance acquisition unit 207 obtains the delay time for each application 10 from the request and response interval between the application 10 and the accelerator 5 (step S801). The performance acquisition unit 207 then outputs the acquired delay time to the transfer queue selection unit 205.

[0120] Next, the device status acquisition unit 301 acquires the device status by counting the number of requests pending on the accelerator 5 (step S802). The device status acquisition unit 301 then acquires the number of pending requests (or the delay time predicted from the number of requests) and outputs it to the transfer queue selection unit 205.

[0121] The transfer queue selection unit 205 refers to the application performance information 250 (Figure 8) and the upper threshold information corresponding to the number of pending requests stored in the memory unit, and determines whether the delay time exceeds the upper threshold, or whether the number of pending requests (or the predicted delay time) exceeds the upper threshold (step S803).

[0122] If either of the transfer queues exceeds the upper threshold (step S803 → Yes), the transfer queue selection unit 205 increases the queue selection ratio (read ratio) of the transfer queue 204 and the transfer queue 204 with a higher priority than the transfer queue 204 by a predetermined amount (step S804).

[0123] On the other hand, in step S803, if neither the delay time nor the number of pending requests (or the predicted delay time) exceeds the upper threshold (step S803 → No), the transfer queue selection unit 205 proceeds to step S805.

[0124] In step S805, the transfer queue selection unit 205 refers to the application performance information 250 (Figure 8) and the lower threshold information corresponding to the number of pending requests stored in the memory unit, and determines whether the delay time is less than the lower threshold, or whether the number of pending requests (or the predicted delay time) is less than the lower threshold.

[0125] Then, if either of the transfer queues is below the lower threshold (step S805 → Yes), the transfer queue selection unit 205 reduces the queue selection ratio (read ratio) of the transfer queue 204 and the transfer queue 204 with a higher priority than the transfer queue 204 by a predetermined number (step S806).

[0126] On the other hand, in step S805, if neither the delay time nor the number of pending requests (or the predicted delay time) is below the lower threshold (step S805 → No), the transfer queue selection unit 205 terminates processing without changing the queue selection ratio (read ratio).

[0127] [Hardware configuration] The accelerator off-road device 100 according to the above embodiment is implemented by a computer 900 having a configuration such as that shown in Figure 22. Figure 22 is a hardware configuration diagram showing an example of a computer 900 that implements the functions of the accelerator offload device 1. Computer 900 includes a CPU 901, RAM 902, ROM 903, HDD 904, accelerator 905, input / output interface (I / F) 906, media interface (I / F) 907, and communication interface (I / F) 908. Accelerator 905 corresponds to accelerator 5 in Figure 1.

[0128] Accelerator 905 is an accelerator 5 (Figure 1) that processes at least one of the data from the communication interface 908 or the data from the RAM 902 at high speed. Alternatively, accelerator 905 may be of a type that returns the execution result to the CPU 901 or RAM 902 after processing from the CPU 901 or RAM 902 (look-aside type). Alternatively, accelerator 905 may be of an in-line type that acts as an intermediary between the communication interface 908 and the CPU 901 or RAM 902 to perform processing.

[0129] The accelerator 905 is connected to the external device 915 via the communication interface 908. The input / output interface 906 is connected to the input / output device 916. The media interface 907 reads and writes data to the recording medium 917.

[0130] The CPU 901 operates based on a program stored in the ROM 903 or HDD 904, and controls each part of the accelerator offload device 1 shown in Figure 1 by executing the program (application) loaded into the RAM 902. This program can also be distributed via a communication line or by recording it on a recording medium 917 such as a CD-ROM. ROM903 stores boot programs executed by CPU901 when the computer 900 starts up, as well as programs that depend on the computer 900's hardware.

[0131] The CPU 901 controls the input / output device 916, which consists of an input unit such as a mouse and keyboard, and an output unit such as a display and printer, via the input / output interface 906. The CPU 901 acquires data from the input / output device 916 via the input / output interface 906 and outputs generated data to the input / output device 916.

[0132] HDD904 stores programs executed by CPU901 and data used by those programs. Communication I / F908 receives data from other devices via a communication network (e.g., NW (Network)) and outputs it to CPU901, and also transmits data generated by CPU901 to other devices via the communication network.

[0133] The media interface 907 reads a program or data stored in the recording medium 917 and outputs it to the CPU 901 via the RAM 902. The CPU 901 loads the program related to the desired processing from the recording medium 917 onto the RAM 902 via the media interface 907 and executes the loaded program. The recording medium 917 can be an optical recording medium such as a DVD (Digital Versatile Disc) or PD (Phase Change Rewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical Disk), a magnetic recording medium, a conductive memory tape medium, or a semiconductor memory.

[0134] For example, when computer 900 functions as an accelerator offload device 1 configured as one of the devices according to this embodiment, the CPU 901 of computer 900 realizes the function of accelerator offload device 1 by executing a program loaded on RAM 902. The HDD 904 stores the data in RAM 902. The CPU 901 reads and executes a program related to the desired processing from the recording medium 917. Alternatively, the CPU 901 may read a program related to the desired processing from another device via a communication network.

[0135] <Effects> The following describes the effects of the accelerator off-road device 1, etc., according to the present invention. The accelerator offload device according to the present invention is an accelerator offload device 1 having an accelerator 5, which offloads the processing of multiple applications 10 with different performance requirements to the accelerator 5, and includes a device pseudo-function unit 201 that receives requests from applications 10 and enqueues the requests in an acceptance queue 202 corresponding to the applications 10, while appearing to communicate with the accelerator 5 by realizing interface functions equivalent to those of the accelerator 5, and acquires metadata attached to the received requests and stores a transfer queue 204 corresponding to a basic priority indicating the priority of the application 10 according to the performance requirements in the acceptance queue 202 for each request. The system is characterized by comprising: a transfer queue determination unit 203 that determines the destination for enqueuing the received request; a reception queue 202 provided for each of the multiple applications 10, which buffers the request and enqueues the request to the transfer queue 204 determined by the transfer queue determination unit 203; a transfer queue selection unit 205 that, according to the priority associated with each transfer queue 204, issues a dequeuing instruction to each transfer queue 204, prioritizing the dequeuing of the transfer queue with the highest priority, based on a predetermined transfer queue selection logic; and a transfer queue 204 provided for each priority, which buffers the request and outputs the request to the device queue 51 of the accelerator 5 in accordance with the dequeuing instruction.

[0136] In this way, the accelerator offload device 1 can prevent performance degradation of applications 10 even when offloading from multiple applications 10 with different performance requirements to the same accelerator 5. Therefore, even in cases where conventional technology cannot offload to the same accelerator 5 due to stringent performance requirements, the accelerator offload device 1 can offload to the same accelerator 5, thereby reducing power consumption.

[0137] Furthermore, with the accelerator offload device 1, in a system that has already offloaded multiple applications 10 to the same accelerator 5, the performance of the high-priority application 10 is guaranteed, thereby improving service quality. Furthermore, the accelerator offload device 1 eliminates traffic limitations to avoid performance impacts in systems that have already offloaded traffic from multiple applications 10 to the same accelerator 5, making it possible to handle more traffic.

[0138] Furthermore, the accelerator offload device 1 further includes a queue limit determination unit 302 that sets a queue limit indicating the upper limit of the number of requests that can be enqueued for each transfer queue 204, and when a transfer queue 204 enqueues a new request, if the number exceeds the queue limit, it stops enqueuing the new request from the acceptance queue 202.

[0139] In this way, the accelerator offload device 1 can stop enqueuing low-priority requests from the acceptance queue 202 by setting a queue limit for the transfer queue 204, and can prioritize processing high-priority requests. Therefore, the accelerator offload device 1 can further reduce the performance impact between multiple applications 10 with different performance requirements.

[0140] Furthermore, the accelerator offload device 1 is further equipped with a performance acquisition unit 207 that acquires a performance delay value indicating the delay time from the time of sending a request and the time of receiving the response between the application 10 and the accelerator 5, and the transfer queue selection unit 205 is characterized in that, when the delay time exceeds a predetermined upper threshold, it changes the transfer queue selection logic and increases the number of items dequeued from the high-priority transfer queue 204 compared to the current time.

[0141] In this way, the accelerator offload device 1 can process high-priority requests with even greater priority if the delay time of a high-priority request exceeds a predetermined upper threshold. Therefore, the accelerator offload device 1 can further reduce the performance impact between multiple applications 10 with different performance requirements.

[0142] Furthermore, the accelerator offload device 1 is further equipped with a performance acquisition unit 207 that acquires a performance delay value indicating the delay time from the time of sending a request and the time of receiving the response between the application 10 and the accelerator 5, and the queue limit determination unit 302 is characterized in that, when the delay time exceeds a predetermined upper limit threshold, it lowers the queue limit set in the transfer queue 204 corresponding to the application by a predetermined number.

[0143] In this way, when the delay time of a high-priority request exceeds a predetermined upper threshold, the accelerator offload device 1 can lower the queue limit set in the transfer queue 204 to further prioritize the processing of high-priority requests. Therefore, the accelerator offload device 1 can further reduce the performance impact between multiple applications 10 with different performance requirements.

[0144] Furthermore, the accelerator offload device 1 is further equipped with a device status acquisition unit 301 that acquires the number of requests pending in the accelerator 5, and the transfer queue selection unit 205 is characterized in that, when the number of pending requests exceeds a predetermined upper threshold, it changes the transfer queue selection logic and increases the number of requests dequeued from the high-priority transfer queue 204 compared to the current number.

[0145] In this way, the accelerator offload device 1 can process high-priority requests with even greater priority when the number of requests pending on the accelerator 5 exceeds a predetermined upper threshold. Therefore, the accelerator offload device 1 can further reduce the performance impact between multiple applications 10 with different performance requirements.

[0146] Furthermore, the accelerator offload device 1 is further equipped with a device status acquisition unit 301 that acquires the number of requests pending in the accelerator 5, and the queue limit determination unit 302 is characterized in that, when the number of pending requests exceeds a predetermined upper limit threshold, it lowers the queue limit set in the transfer queue 204 corresponding to the application 10 by a predetermined number.

[0147] In this way, when the number of requests accumulating in the accelerator 5 exceeds a predetermined upper threshold, the accelerator offload device 1 can lower the queue limit set in the transfer queue 204 and process high-priority requests with even greater priority. Therefore, the accelerator offload device 1 can further reduce the performance impact between multiple applications 10 with different performance requirements.

[0148] Furthermore, the accelerator offload device 1 is characterized by further comprising a real-time determination unit 208 that, if the metadata attached to the received request does not contain priority information indicating information that can determine the priority of the request, calculates the time budget remaining for the request, and if the calculated time budget is smaller than a predetermined time threshold, controls the system to raise the priority of the request from the basic priority determined by the transfer queue determination unit 203.

[0149] In this way, the accelerator offload device 1 can route requests with a smaller time budget to a higher-priority transfer queue 204. Therefore, the accelerator offload device 1 can further reduce the performance impact between multiple applications 10 with different performance requirements.

[0150] Furthermore, the accelerator offload device 1 is characterized by further comprising a bandwidth reservation unit 303 that acquires predictive information regarding the increase in request traffic and outputs an instruction to the transfer queue determination unit 203 to stop enqueuing to high-priority transfer queues in advance.

[0151] In this way, the accelerator offload device 1 can minimize request delays when bursts of requests are anticipated. Therefore, the accelerator offload device 1 can further reduce the performance impact between multiple applications 10 with different performance requirements.

[0152] It should be noted that the present invention is not limited to the embodiments described above, and many modifications are possible within the technical concept of the present invention by those with ordinary skill in the art. [Explanation of Symbols]

[0153] 1. Accelerator Off-Road Device 5. Accelerator (ACC) 7. External Controller 10. Applications (APL) 20 Packet Processing Unit 30 Off-road Management Department 50 HW 51 Device Queue 52 IP cores 55 VF 201 Device Pseudo-Function Unit 202 Reception Queue 203 Transfer Queue Determination Unit 204 Transfer Queue 205 Transfer Queue Selection Section 206 Physical Device Transfer Unit 207 Performance acquisition section 208 Real-time discrimination unit 210 Reception Queue Information 220 Transfer Queue Determination Information 230 Transfer Queue Information 240 Transfer Queue Selection Information 250 Application Performance Information 301 Device Status Acquisition Unit 302 Queue Limit Determination Unit 303 Bandwidth Reservation Section

Claims

1. An accelerator offload device having an accelerator, which offloads the processing of multiple applications with different performance requirements to the accelerator, A device pseudo-function unit that simulates communication with the accelerator by implementing an interface function equivalent to that of the accelerator, receives a request from the application, and enqueues the request in the reception queue corresponding to the application, A transfer queue determination unit obtains metadata attached to the received request and, for each request, determines a transfer queue corresponding to the basic priority indicating the application priority according to the performance requirements as the enqueue destination for the request stored in the reception queue. A receiving queue is provided for each of the aforementioned multiple applications, which buffers the request and enqueues the request to the transfer queue determined by the transfer queue determination unit, A transfer queue selection unit, which, according to the priority assigned to each of the transfer queues, issues a dequeue instruction to each of the transfer queues to prioritize dequeuing the transfer queue with the highest priority, based on a predetermined transfer queue selection logic, A transfer queue is provided for each priority level, buffers the request, and outputs the request to the accelerator's device queue according to the dequeue instruction, An accelerator off-road device characterized by comprising the following:

2. Each of the aforementioned transfer queues is further provided with a queue limit determination unit that sets a queue limit indicating the upper limit of the number of requests that can be enqueued. When the transfer queue enqueues a new request, if the queue limit is exceeded, the enqueue of the new request from the acceptance queue will be stopped. The accelerator off-road device according to claim 1, characterized by the following:

3. The system further includes a performance acquisition unit that acquires a performance delay value indicating the delay time between the application and the accelerator, based on the transmission time of the request and the reception time of the response. The transfer queue selection unit modifies the transfer queue selection logic when the delay time exceeds a predetermined upper threshold, thereby increasing the number of transfer queues dequeued from the higher priority transfer queues compared to the current state. The accelerator off-road device according to claim 1 or claim 2, characterized by the above.

4. The system further includes a performance acquisition unit that acquires a performance delay value indicating the delay time between the application and the accelerator, based on the transmission time of the request and the reception time of the response. The queue limit determination unit, when the delay time exceeds a predetermined upper limit threshold, reduces the queue limit set for the transfer queue corresponding to the application by a predetermined number. The accelerator off-road device according to claim 2, characterized by the following:

5. The device further includes a device status acquisition unit that acquires the number of requests pending in the accelerator, The transfer queue selection unit modifies the transfer queue selection logic when the number of pending requests exceeds a predetermined upper threshold, thereby increasing the number of requests dequeued from the higher-priority transfer queues compared to the current state. The accelerator off-road device according to claim 1 or claim 2, characterized by the above.

6. The device further includes a device status acquisition unit that acquires the number of requests pending in the accelerator, The queue limit determination unit, when the number of pending requests exceeds a predetermined upper limit threshold, lowers the queue limit set for the transfer queue corresponding to the application by a predetermined number. The accelerator off-road device according to claim 2, characterized by the following:

7. The system further includes a real-time determination unit that, if the metadata attached to the received request does not contain priority information indicating information that can determine the priority of the request, calculates the time budget remaining for the request, and if the calculated time budget is smaller than a predetermined time threshold, controls the system to raise the priority of the request from the basic priority determined by the transfer queue determination unit. The accelerator off-road device according to claim 1 or claim 2, characterized by the above.

8. The bandwidth reservation unit further includes a unit that obtains predictive information regarding the increase in traffic for the aforementioned request and outputs an instruction to the transfer queue determination unit to stop enqueuing to a high-priority transfer queue in advance. The accelerator off-road device according to claim 1 or claim 2, characterized by the above.

9. An accelerator offloading method for an accelerator offloading device having an accelerator and offloading the processing of multiple applications with different performance requirements to the accelerator, The aforementioned accelerator off-road device is The steps include: receiving a request from the application and enqueuing the request in the reception queue corresponding to the application, by implementing an interface function equivalent to that of the accelerator, thereby making it appear as if communication is being made with the accelerator; The steps include: obtaining metadata attached to the received request, determining for each request a transfer queue corresponding to the basic priority indicating the application priority according to the performance requirements, as the enqueue destination for the request stored in the reception queue; The receiving queue, provided for each of the multiple applications, buffers the request and enqueues the request in the determined transfer queue, The steps include: issuing a dequeue instruction to each of the aforementioned transfer queues, according to the priority assigned to each of the aforementioned transfer queues, using a predetermined transfer queue selection logic, to prioritize dequeuing the transfer queue with the highest priority; The transfer queues provided for each priority level buffer the request and, in accordance with the dequeue instruction, output the request to the accelerator's device queue. An accelerator offloading method characterized by performing the following.

10. A program for causing a computer to function as an accelerator off-road device according to claim 1 or claim 2.

Images