Computational processing offload system, computational processing offload method, and program

Abstract

A server (200) has a userland APL (230) that bypasses an OS (220) and cooperates with an accelerator (212). The userland APL (230) has an ACC-NIC common data parsing unit (232) that parses reception data that uses a common format for input data for an ACC usage function and NIC reception data.

Description

[Technical field]

[0001] The present invention relates to a computation offload system, a computation offload method, and a program. [Background technology]

[0002] With the advancement of cloud computing, it is becoming common to simplify the configuration of client machines by offloading some of the computationally intensive processing from the client machines deployed at the user site to servers at remote sites (such as data centers located near the users) via a network (hereafter referred to as NW).

[0003] FIG. 14 is a diagram illustrating the device configuration of the offload system via the NW. As shown in FIG. 14, the offload system via the NW1 includes a client 10 installed at a user site, and a server 50 connected to the client 10 via the NW1. The client 10 includes client HW (hardware) 20, an OS (Operating System) 30, and an application (hereinafter, referred to as APL as appropriate) 40. The APL 40 includes a client application unit 41, an accelerator (hereinafter, referred to as ACC as appropriate) ACC-using IF 42, and middleware 43. The ACC-using IF 42 is an ACC (Accelerator: calculation accelerator device)-using IF specification made of OpenCL (Open Computing Language) or the like.

[0004] The client 10 does not include a calculation accelerator device (ACC) such as a Field Programmable Gate Array (FPGA) / Graphics Processing Unit (GPU). The client 10 includes a network interface card (NIC) 21 mounted on the client HW 20 .

[0005] The client application unit 41 is a program executed in a user space. The offload system via the NW is built on the premise of using a prescribed API (Application Programming Interface) such as OpenCL, and performs input and output with these APIs. The client application unit 41 is an application that runs on the client 10 and conforms to a standard API for ACC access. The client application unit 41 that runs on the client 10 is expected to perform image processing and the like, and therefore requires low computation latency.

[0006] The server 50 includes a server HW 60, an OS 70, an APL 80, and an accelerator (ACC) 62 on the server HW 60. The APL 80 includes middleware 81 for offloading. The server 50 is equipped with one or more accelerators 62 . The server 50 includes a NIC 61 mounted on the server HW 60 .

[0007] The client 10 and the server 50 can communicate with each other via their respective NICs 21, 61 and NW1.

[0008] In the off-road system shown in FIG. 14, it is preferable that the following requirements 1 to 3 are satisfied. Requirement 1: No changes are made to the client application unit 41 (transparency). Requirement 2: The overhead in ACC calculation offload via NW1 must be small (low latency). Requirement 3: When offloading ACC calculations via NW1, the overhead fluctuation range must be small (low jitter).

[0009] An existing technology for transparent accelerator processing offload via a network is "remote offloading by packetizing the function name and arguments of the accelerator standard IF function and transferring them over the network" (see Non-Patent Document 1).

[0010] Fig. 15 is a diagram for explaining an accelerator standard IF offload system using the OS protocol stack described in Non-Patent Document 1. In explaining Fig. 15, the same components as those in Fig. 14 are given the same reference numerals. The solid arrow in FIG. 15 indicates an off-road outbound route, and the dashed arrow in FIG. 15 indicates an off-road return route. As shown in FIG. 15, the accelerator standard IF offload system includes a client 10 and a server 50 connected to the client 10 via a NW1. 15 includes a client HW 20, an OS 30, and an application (APL) 40. The client HW 20 also includes a NIC 21. The OS 30 includes an L4 / L3 protocol stack unit 31 and a NIC driver unit 32 . APL 40 has a client application unit 41, an ACC function proxy reception unit 44, an ACC function / return value packetization unit 45, an ACC function / argument data parsing unit 46, and an ACC function proxy response unit 47. Hereinafter, in this specification, "·" is used to mean "and."

[0011] The server 50 shown in FIG. 15 includes a server HW 60, an OS 70, an APL 80, a NIC 61 on the server HW 60, and an accelerator 62. The OS 70 includes an L4 / L3 protocol stack unit 71 and a NIC driver unit 72 . The APL 80 has an ACC function and argument data parsing unit 82 , an ACC function proxy execution unit 83 , and an ACC function and return value packetization unit 84 .

[0012] Next, the off-road outward route and the off-road return route will be described. Off-road outbound The client application unit 41 of the client 10 has input and output with a prescribed API such as OpenCL. The ACC function proxy acceptance unit 44 is realized as middleware having an IF compatible with a prescribed API. The ACC function proxy acceptance unit 44 has an IF equivalent to a prescribed API such as OpenCL, and accepts API calls from the client application unit 41. The ACC function proxy acceptance unit 44 accepts a function name and arguments from the client application unit 41 as input (see symbol a in FIG. 15). The ACC function proxy acceptance unit 44 passes the function name and arguments to the ACC function and return value packetization unit 45 as output (see symbol b in FIG. 15).

[0013] The ACC function and return value packetization unit 45 passes a transmission packet to the L4 / L3 protocol stack unit 31 based on the accepted function name and argument (see symbol c in FIG. 15). The L4 / L3 protocol stack unit 31 makes the input packet conform to the L4 / L3 protocol, and the NIC driver unit 32 passes the transmission packet conforming to the L4 / L3 protocol to the NIC 21 (see symbol d in FIG. 15). The NIC 21 transmits the packet to the NIC 61 of the server 50 connected via the NW1.

[0014] The NIC driver unit 72 of the server 50 receives a packet from the NIC 61 (see symbol e in FIG. 15) and passes it to the L4 / L3 protocol stack unit 71. The L4 / L3 protocol stack unit 71 converts the received packet conforming to the L4 / L3 protocol into processable packet data and passes it to the ACC function and argument data parsing unit 82 (see symbol f in FIG. 15). The ACC function and argument data parsing unit 82 deserializes the packet data and passes the function name and execution result to the ACC function proxy execution unit 83 (see symbol g in FIG. 15).

[0015] The ACC function proxy execution unit 83 offloads (see symbol h in FIG. 15) the accelerator function and argument data based on the received function name and execution result to the accelerator (ACC) 62 for execution.

[0016] Off-road return trip The accelerator 62 executes the ACC function and passes the function name and the function execution result to the ACC function proxy execution unit 83 (see symbol i in FIG. 15). The ACC function proxy execution unit 83 passes the function name and function execution result from the accelerator 62 to an ACC function and return value packetization unit 84 (see symbol j in FIG. 15). The ACC function / return value packetization unit 84 packetizes the passed function name and function execution result and passes it to the L4 / L3 protocol stack unit 71 (see symbol k in FIG. 15). The L4 / L3 protocol stack unit 71 makes the packet data compliant with the L4 / L3 protocol, and the NIC driver unit 72 passes the packet data compliant with the L4 / L3 protocol to the NIC 61 (see reference character l in FIG. 15). The NIC 61 transmits a packet to the NIC 21 of the client 10 connected via the NW 1 .

[0017] The NIC driver unit 32 of the client 10 receives a packet from the NIC 21 (see symbol m in FIG. 15) and passes it to the L4 / L3 protocol stack unit 31. The L4 / L3 protocol stack unit 31 converts the received packet conforming to the L4 / L3 protocol into processable packet data and passes it to the ACC function and argument data parsing unit 46 (see symbol n in FIG. 15). The ACC function and argument data parsing unit 46 deserializes the function name and execution result into serial data and passes it to the ACC function proxy response unit 47 (see symbol o in FIG. 15). The ACC function proxy response unit 47 passes the received serial data to the client application unit 41 as accelerator processing data (see symbol p in FIG. 15).

[0018] In the above configuration, both the client 10 and the server 50 use a dedicated NIC (for example, a Remote Direct Memory Access Host Channel Adapter (RDMA HCA)) with a protocol stack processing function. Both the client 10 and the server 50 have a protocol stack function unit in the OS 30, 70. [Prior art documents] [Non-patent literature]

[0019] [Non-Patent Document 1] “rCUDA v20.07alpha User's Guide,” The rCUDA Team, July, 2020., [online], [Retrieved December 24, 2021], Internet 〈 URL : http: / / www.rcuda.net / pub / rCUDA_guide.pdf 〉 Summary of the Invention [Problem to be solved by the invention]

[0020] However, in the offload system described in Non-Patent Document 1, as shown in Fig. 13, the L4 / L3 protocol stack unit 31 of the OS 30 is independent of the ACC function and argument data parsing unit 46 and the ACC function and return value packetizing unit 45. Similarly, the L4 / L3 protocol stack unit 71 of the OS 70 is independent of the ACC function and argument data parsing unit 82 and the ACC function and return value packetizing unit 84. For this reason, overhead occurs in the link between the L4 / L3 protocol stack function of the OS and the ACC function and argument data (hereinafter, linkage means the ability to parse, generate packets, and execute processing), which poses a problem that it is difficult to reduce latency.

[0021] The present invention has been made in consideration of this background, and its objective is to reduce data combination and conversion processing when a server offloads distributed received data to an accelerator, thereby achieving low latency. [Means for solving the problem]

[0022] In order to solve the above-mentioned problems, the present invention provides a computational processing offload system comprising a client and a server connected via a network and a NIC (Network Interface Card), in which the client offloads specific processing of an application to an accelerator located on the server for computational processing, wherein the server has a userland application that bypasses the OS and works with the accelerator, and the userland application has an ACC-NIC common data parsing unit that parses received data that has a common input data format for ACC (accelerator)-used functions and a NIC received data format. Effect of the Invention

[0023] According to the present invention, when a server offloads distributed received data to an accelerator, data binding and conversion processing can be reduced, thereby realizing low latency. [Brief description of the drawings]

[0024] [Figure 1] 1 is a schematic configuration diagram of a computation offload system according to an embodiment of the present invention; [Diagram 2] FIG. 2 is a diagram illustrating an offload processing flow of the computation offload system according to the embodiment of the present invention. [Diagram 3] This is a data structure diagram of an accelerator function / argument data packet, which is output data of the ACC-NIC common data creation unit of the computational offload system of an embodiment of the present invention and which corresponds to input to the ACC-NIC common data parsing unit. [Figure 4] 1 is a data structure diagram of an accelerator function return value packet of the computation offload system according to an embodiment of the present invention. [Diagram 5] 11 is a flowchart showing an offload process during transmission by a client of the computation offload system according to the embodiment of the present invention. [Figure 6]11 is a flowchart showing an offload process during transmission by a client of the computation offload system according to the embodiment of the present invention. [Figure 7A] 5 is a flowchart showing an offload process of a server in the computation offload system according to the embodiment of the present invention. [Figure 7B] 5 is a flowchart showing an offload process of a server in the computation offload system according to the embodiment of the present invention. [Figure 8] 11 is a flowchart showing a parsing process of an ACC-NIC common data parsing unit of the computation offload system according to the embodiment of the present invention. [Figure 9] FIG. 11 is a diagram showing a data structure on a memory including a subsequent data address storage area of ​​an accelerator function / argument data packet of the computation offload system according to the embodiment of the present invention. [Figure 10] 11 is a flowchart showing an offload process at the time of reception by a client of the computation offload system according to the embodiment of the present invention. [Figure 11] FIG. 2 is a schematic configuration diagram of a computation offload system according to <Modification 1> of an embodiment of the present invention. [Figure 12] FIG. 11 is a schematic configuration diagram of a computation offload system according to <Modification 2> of an embodiment of the present invention. [Figure 13] FIG. 2 is a hardware configuration diagram illustrating an example of a computer that realizes a function of a server in the computation offload system according to the embodiment of the present invention. [Figure 14] FIG. 1 is a diagram illustrating the device configuration of an offload system via a network. [Figure 15] FIG. 1 is a diagram illustrating an accelerator standard IF offload system using the OS protocol stack described in Non-Patent Document 1. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] Hereinafter, a computation offload system and the like in an embodiment for carrying out the present invention (hereinafter, referred to as "the present embodiment") will be described with reference to the drawings. (Embodiment) [overview] Fig. 1 is a schematic diagram of a computation offload system according to an embodiment of the present invention. This embodiment is an example of application to offload processing using Linux (registered trademark) XDP (eXpress Data Path) / eBPF (Berkeley Packet Filter). Fig. 2 is a diagram for explaining the offload processing flow of the computation offload system 1000 of Fig. 1. The offload processing flow of Fig. 2 will be described in detail in the operation description. As shown in FIGS. 1 and 2, a computation offload system 1000 includes a client 100 and a server 200 connected to the client 100 via a NW1. In the computation offload system 1000, the client 100 offloads specific processing of an application to an accelerator 212 arranged in a server 200 for computation.

[0026] [Client 100] The client 100 includes a client HW 110, an OS 120, and a user land APL .

[0027] Client HW110 The client HW 110 includes a NIC 111 . The NIC 111 is a NIC hardware that realizes a network interface. In the <transmission pattern>, the NIC 111 receives, as an input, a "transmission packet" from the polling data transmission / data acquisition unit 134 via a NIC driver (not shown). In the <transmission pattern>, the NIC 111 passes, as an output, a "transmission packet" to the server HW 210 connected via the NW 1. In the <reception pattern>, the NIC 111 accepts, as input, a "reception packet" from the server 200 connected via the NW 1. In the <reception pattern>, the NIC 111 passes, as output, the "reception packet" to the polling data transmission / data acquisition unit 134 via a NIC driver (not shown).

[0028] "Userland APL130" The Userland APL130 has a user application section 131, an ACC function proxy reception section 132, an ACC-NIC common data creation section 133, a polling data transmission / data acquisition section 134, a function / argument data parsing section 135, and an ACC function proxy response section 136.

[0029] <User application section 131> The user application section 131 is a program executed in the user space. The user application section 131 is constructed on the premise of using specified APIs such as OpenCL and performs input / output with these APIs. The user application section 131 has, as output, a "function name / argument" for the ACC function proxy reception section 132. The user application section 131 receives, as input, the function execution result from the ACC function proxy response section 136. The user application section 131 may also have a result output destination such as image drawing to a display as another output destination.

[0030] <ACC function proxy reception section 132> The ACC function proxy reception section 132 is realized as middleware having an interface compatible with the specified API. The ACC function proxy reception section 132 has an interface equivalent to the specified APIs such as OpenCL and receives API calls from the user. The ACC function proxy reception section 132 is prepared as a binary file separate from the specified user application and is realized in the form of a "dynamic library" in which dynamic link / calls are made at the time of execution.

[0031] The ACC function proxy reception section 132 receives, as input, a "function name / argument" from the user application section 131. The ACC function proxy reception section 132 passes, as output, the "function name / argument" to the ACC-NIC common data creation section 133. The ACC function proxy reception section 132 may also be in the form of a "static library" that is linked to the user application at the time of program generation and executed integrally.

[0032] <ACC-NIC Common Data Creation Unit 133> The ACC-NIC Common Data Creation Unit 133 converts the input function name and arguments into single data as an L2 frame and its payload that can be transmitted by the NIC 111. Note that the data format will be described later with reference to Figure 3. The ACC-NIC Common Data Creation Unit 133 receives "function name · arguments" from the ACC Function Proxy Reception Unit 132 as input. The ACC-NIC Common Data Creation Unit 133 passes "transmission data" to the Polling Data Transmission / Data Acquisition Unit 134 as output.

[0033] Here, the data format may be not only an L2 frame but also data with L3 and L4 headers added. Also, the L3 and L4 headers may be other than TCP / IP (Transmission Control Protocol / Internet Protocol), such as those that discard a part of L3 / L4 and use only L3. The packet format may include not only the function name and arguments but also an ID that can uniquely identify the accelerator to be used.

[0034] Figure 3 is a data structure diagram of the accelerator function / argument data packet 350 showing an example of the output data of the ACC-NIC Common Data Creation Unit 133. This accelerator function / argument data packet 350 is also used as the input data of the ACC-NIC Common Data Parsing Unit 232 of the server 200 described later.

[0035] In this embodiment, the data format of the NICs 111, 211 and the accelerator 212 is standardized, and the data in the memory that is distributed and received as packets is transferred directly to the accelerator 212. For this reason, the data structure is standardized. Specifically, the data structure created by the ACC-NIC common data creation unit 133 is the accelerator function / argument data packet 350 shown in FIG. 3, and the data structure used in the batch transfer by the distributed data ACC batch transfer instruction unit 234 of the server 200 described later is the accelerator function / return value packet 360 shown in FIG. 4 described later. Therefore, the data structure of the accelerator function / argument data packet 350 (FIG. 3) and the accelerator function / return value packet 360 (FIG. 4) are the same. By standardizing the data format of the NICs 111 and 211 and the accelerator 212, data received by the NIC 211 is in a format that the ACC function proxy execution unit 233 can read as is.

[0036] As shown in FIG. 3, the accelerator function / argument data packet 350 includes an L2 frame 351 (0 to 14 bytes), a function ID 352 (up to 34 bytes), a final data bit 353 (up to 42 bytes), a subsequent data address storage area 354 (up to 46 bytes), an argument <1> 355 (~50 bytes), and arguments <2> The actual data of the accelerator function / argument data packet 350 includes an L2 frame 351, a function ID 352, and a subsequent data address storage area 354 excluding the final data bit 353, an argument <1> 355 and arguments <2> The number is 356.

[0037] The subsequent data address storage area 354 is an example of an area in which the accelerator 212 records the address of subsequent data. The subsequent data address storage area 354 may be secured in an area in which subsequent data is saved after reception, without being included in the frame to be transmitted or received.

[0038] The accelerator function and argument data packet 350 has a data structure suitable for parsing in an FPGA circuit by making each data a fixed length and fixed position. The packet format shown in Fig. 3 may include not only the function name and arguments but also an ID that can uniquely identify the accelerator to be used.

[0039] <Polling data transmission / data acquisition unit 134> The polling data transmission / data acquisition unit 134 communicates with the NIC 111 and transmits / receives data to / from the NIC 111. This transmission / reception is performed through continuous access by polling in a busy loop without using interrupts. Also, to eliminate the need for kernel intervention, it is executed as a userland program.

[0040] The polling data transmission / data acquisition unit 134 receives "transmission data" as a transmission pattern input from the ACC-NIC common data creation unit 133. The polling data transmission / data acquisition unit 134 passes the "transmission data" to the NIC 111 as a transmission pattern output.

[0041] The polling data transmission and data acquisition unit 134 receives, as a reception pattern input, a "received packet" from the NIC 111. The polling data transmission and data acquisition unit 134 passes the "received packet" to the function and argument data parsing unit 135 as a reception pattern output. Here, the polling in the busy loop may be performed mainly in the kernel space.

[0042] <Function / Argument Data Parsing Section 135> The function / argument data parsing unit 135 deserializes the packet data input from the server 200 side according to a predetermined protocol format, and acquires the function name and execution result.

[0043] The function and argument data parsing unit 135 deserializes the input packet data to obtain the “function name and execution result” from the input data, and passes it to the ACC function proxy response unit 136 .

[0044] <ACC function proxy response unit 136> The ACC function proxy response unit 136 is implemented as middleware with an IF compatible with the specified API. The ACC function proxy response unit 136 is prepared as a binary file separate from the user application unit 131 and is implemented in the form of a "dynamic library" where dynamic link calls are made during execution.

[0045] The ACC function proxy response unit 136 receives "function name · execution result" from the function · argument data parsing unit 135 as input. The ACC function proxy response unit 136 passes "return value" to the user application unit 131 as output.

[0046] The ACC function proxy response unit 136 may also be in the form of a "static library" that is linked to the user application unit 131 during program generation and executed together with the user application unit 131.

[0047] [Server 200] The server 200 includes a server HW210, an OS 220, and a userland APL 230.

[0048] 《Server HW210》 The server HW210 has a NIC 211 and an accelerator 212.

[0049] <nic211> The NIC 211 is NIC hardware that realizes a network interface. In the <transmission pattern>, the NIC 211 receives, as input, a "transmission packet" from the response data transmission unit 236. In the <transmission pattern>, the NIC 211 passes, as output, a "transmission packet" to the NIC 111 of the client 100 connected via the NW1. In the <reception pattern>, the NIC 211 accepts, as input, a "reception packet" from the NIC 111 of the client 100 connected via the NW 1. In the <reception pattern>, the NIC 211 passes, as output, the "reception packet" to the polling data acquisition / ACC offload continuous instruction unit 231 via a NIC driver (not shown).

[0050] <Accelerator 212> The accelerator 212 is a calculation unit hardware that performs a specific calculation at high speed based on an input from the CPU. The accelerator 212 corresponds to a GPU / FPGA connected to the server 200. The accelerator 212 is equipped with a scatter-gather DMA and is capable of transferring data distributed on the host memory all at once.

[0051] In the <transmission pattern>, the accelerator 212 receives, as an input, “ACC instruction data” from the distributed data ACC batch transfer instruction unit 234. In the <transmission pattern>, the accelerator 212 passes, as an output, “execution result” to the ACC function & return value data acquisition unit 235.

[0052] The accelerator 212 may be a system on chip (SoC) or the like in which a CPU and an accelerator are integrated into one chip. If the accelerator 212 is not installed, the ACC function proxy execution unit 233 may not be present.

[0053] 《Userland APL230》 As shown in FIG. 1, the userland APL230 includes a polling data acquisition·ACC offload continuous instruction unit (hereinafter referred to as the ACC offload continuous instruction unit) 231, an ACC-NIC common data parsing unit 232, an ACC function proxy execution unit 233, a distributed data ACC batch transfer instruction unit 234, an ACC function·return value data acquisition unit 235, and a response data transmission unit 236 (see also FIG. 2).

[0054] <ACC offload continuous instruction unit 231> The ACC offload continuous instruction unit 231 performs data arrival confirmation by polling in a busy loop on the NIC 211 of the server HW210. When data has arrived, it performs reception processing and continuously instructs the ACC-NIC common data parsing unit 232 to continuously execute the parsing of the ACC offload process in succession to that process.

[0055] The ACC offload continuous instruction unit 231 accepts a "received packet" from the destination NIC 111 as input. Note that the input confirmation is detected via polling from the ACC offload continuous instruction unit 231 to the NIC 111. The ACC offload continuous instruction unit 231 instructs the parsing of the ACC execution data to the ACC-NIC common data parsing unit 232 as output. Here, the data format conforms to the ACC-NIC common data creation unit 133.

[0056] Note that the method for detecting packet arrival may be detection by interrupt instead of polling.

[0057] <ACC-NIC common data parsing unit 232> The ACC-NIC common data parsing unit 232 parses the received data that standardizes the input data format of the ACC utilization function and the NIC reception data format. Specifically, the ACC-NIC common data parsing unit 232 parses the data received from the ACC offload continuous instruction unit 231 and detects whether it is the last frame of the function execution data divided into multiple parts. At this time, the data format conforms to that of the ACC-NIC common data creation unit 133, and the latter half of the data structure is in a form that can be used without conversion for ACC offloading in the ACC function proxy execution unit 233 and the distributed data ACC batch transfer instruction unit 234. Note that this sequence and conditional branching will be described later in the flow of FIG. 8.

[0058] Here, whether it is the last data of the divided data is determined by referring to a specific bit in the data (refer to the last data bit in FIG. 3). When the reception of the final data is detected, the ACC function proxy execution unit 233 is called with a list of a plurality of unbound received data areas as an argument. For example, at the time of receiving each frame, in the case of the second and subsequent receptions, the address of the latest received frame is stored in the "subsequent data address storage area" (FIG. 3) of the previous received data storage destination to record the relationship between the frames. Note that the data format conforms to that of the ACC-NIC common data creation unit 133.

[0059] <ACC function proxy execution unit 233> Based on the input multiple unbound accelerator execution data, the ACC function proxy execution unit 233 extracts the data transfer content to the ACC excluding the function ID and the final bit, etc., and gives an instruction to the distributed data ACC batch transfer instruction unit 234. These processes are executed only by reference without involving copy processing for unbound data.

[0060] In the <runtime pattern>, the ACC function proxy execution unit 233 receives, as input, a list of accelerator function execution data from the ACC-NIC common data parsing unit 232. In the <runtime pattern>, the ACC function proxy execution unit 233 passes, as output, to the distributed data ACC batch transfer instruction unit 234, a list of data to be transferred to the accelerator 212, among the accelerator function execution data.

[0061] In the <result response pattern>, the ACC function proxy execution unit 233 receives an "execution result" from the ACC function and return value data acquisition unit 235 as an input (see the dashed line between the ACC function proxy execution unit 233 and the ACC function and return value data acquisition unit 235 in FIG. 1). In the <result response pattern>, the ACC function proxy execution unit 233 passes a "function name and function execution result" to the response data transmission unit 236 as an output (see the dashed line between the ACC function proxy execution unit 233 and the response data transmission unit 236 in FIG. 1). That is, in the <result response pattern>, the ACC function proxy execution unit 233 calls the ACC function and return value data acquisition unit 235 as a function and passes its "function name and function execution result" to the response data transmission unit 236. For this reason, the "execution result" of the ACC function and return value data acquisition unit 235 is returned to the ACC function proxy execution unit 233 once. Alternatively, it is also possible for the ACC function / return value data acquisition unit 235 to directly pass the “function name / function execution result” to the response data sending unit 236 (see the solid line between the ACC function / return value data acquisition unit 235 and the response data sending unit 236 in Figure 1).

[0062] <Distributed data ACC batch transfer instruction unit 234> The scattered data ACC batch transfer instruction unit 234 instructs the accelerator 212 to batch transfer the data scattered and received as packets by the ACC-NIC common data parsing unit 232 to the accelerator 212 in the scattered state on the memory of the user land. Specifically, based on the list of input unbound multiple data regions, the scattered data ACC batch transfer instruction unit 234 instructs the scatter-gather DMA function of the accelerator 212 to batch transfer multiple regions to the accelerator 212 without performing data binding. The scattered data ACC batch transfer instruction unit 234 receives, as input, a list of data to be transferred from the ACC function proxy execution unit 233 and instructs the data transfer to the accelerator 212.

[0063] <ACC function · return value data acquisition unit 235> The ACC function · return value data acquisition unit 235 monitors the completion of the operation in the accelerator 212 by polling using a busy loop. When the completion is detected, it acquires the execution result of the accelerator and the parameters (such as execution success / failure) representing the state of the result.

[0064] The ACC function · return value data acquisition unit 235 monitors the accelerator 212 by polling in a busy loop and detects the completion of the process. Here, when the completion is detected, it continuously acquires the operation result by the accelerator. The ACC function · return value data acquisition unit 235 responds, as output, the acquired execution result (return value) to the ACC function proxy execution unit 233.

[0065] In this embodiment, in response to a function call from ACC function proxy execution unit 233, ACC function / return value data acquisition unit 235 once responds to ACC function proxy execution unit 233 with the acquired execution result (return value), and ACC function proxy execution unit 233 then sends the "function name / execution result" to response data transmission unit 236. Alternatively, an embodiment in which ACC function / return value data acquisition unit 235 passes the function name and execution result of accelerator 212 to response data transmission unit 236 may be used (see the solid line between ACC function / return value data acquisition unit 235 and response data transmission unit 236 in FIG. 1).

[0066] <Response data transmission unit 236> The response data transmission unit 236 creates response data based on the input function name and execution result, and instructs the NIC 111 to transmit it. The response data transmission unit 236 receives as input "function name and arguments (execution result is stored as an argument)" from the ACC function and return value data acquisition unit 235. The response data transmission unit 236 passes the execution result data to the NIC 111 as output. The data format at this time is the format shown in FIG. 4 described later.

[0067] If the size of the response data is large, it is also possible to have a function for dividing and sending the data.

[0068] FIG. 4 is a data structure diagram of the accelerator function return value packet 360. The accelerator function return value packet 360 is a data format used when the response data transmission unit 236 passes the execution result data to the NIC 111 as output. As described above, in this embodiment, the data format of the NICs 111 and 211 and the accelerator 212 is standardized, and data in memory that is distributed and received as packets is transferred to the accelerator 212 as is.

[0069] The accelerator function return value packet 360 includes an L2 frame 361 (0 to 14 bytes), a function ID 362 (up to 34 bytes), a final data bit 363 (up to 42 bytes), a subsequent data address storage area 364 (up to 46 bytes), an argument <1> 365 (~50 bytes), plus arguments <2> The actual data of the accelerator function return value packet 360 includes a L2 frame 361, a function ID 362, and a subsequent data address storage area 364 excluding the final data bit 363, an argument 366 (up to 54 bytes), and an execution result is stored as an argument. <1> 365 and arguments <2> The number is 366. The subsequent data address storage area 364 is an example of an area in which the accelerator 212 records the address of the subsequent data.

[0070] The operation of the computation offload system 1000 configured as described above will now be described. [Overview of the operation of the computation offload system 1000] The offload processing flow of the computation offload system 1000 will be described with reference to Fig. 2. The same components as in Fig. 1 are denoted by the same reference numerals. The solid arrow in FIG. 2 indicates an off-road outbound route, and the dashed arrow in FIG. 2 indicates an off-road return route.

[0071] Off-road outbound 2, the ACC function proxy reception unit 132 of the user land APL 130 of the client 100 receives as input the "function name and arguments" from the user application unit 131 (see symbol aa in FIG. 2). The ACC function proxy reception unit 132 of the client 100 passes the "function name and arguments" as output to the ACC-NIC common data creation unit 133 (see symbol bb in FIG. 2).

[0072] The ACC-NIC common data creation unit 133 receives as input the "function name and arguments" from the ACC function proxy reception unit 132. The ACC-NIC common data creation unit 133 converts the input function name and arguments into a single piece of data, an L2 frame that can be transmitted by the NIC and its payload. The ACC-NIC common data creation unit 133 passes as output the "transmission data" to the polling data transmission / data acquisition unit 134 (see symbol cc in FIG. 2).

[0073] The polling data transmission / data acquisition unit 134 receives "transmission data" as a transmission pattern input from the ACC-NIC common data creation unit 133. The polling data transmission / data acquisition unit 134 communicates with the NIC 111 and transmits and receives data to the NIC 111. The polling data transmission / data acquisition unit 134 passes the "transmission data" to the NIC 111 as a transmission pattern output (see symbol dd in FIG. 2).

[0074] In the <transmission pattern>, the NIC 111 receives, as an input, a "transmission packet" from the polling data transmission / data acquisition unit 134 via a NIC driver (not shown). In the <transmission pattern>, the NIC 111 passes, as an output, a "transmission packet" to the NIC 211 of the server HW 210 connected via the NW 1.

[0075] In the <reception pattern>, the NIC 211 of the server HW 210 accepts, as input, a “reception packet” from the NIC 111 of the client 100 connected via the NW 1. In the <reception pattern>, the NIC 211 passes, as output, the “reception packet” to the ACC offload continuous instruction unit 231 via a NIC driver (not shown).

[0076] The ACC offload continuous instruction unit 231 confirms whether data has arrived by polling the NIC 211 of the server HW 210 in a busy loop (see symbol ee in Figure 2), and if data has arrived, it performs reception processing and instructs the ACC-NIC common data parse unit 232 to continuously execute parse of the ACC offload processing following that processing (see symbol ff in Figure 2).

[0077] The ACC-NIC common data parsing unit 232 parses the data received from the ACC offload continuous instruction unit 231 and detects whether it is the last frame of the function execution data divided into multiple parts. When the ACC-NIC common data parsing unit 232 detects that the final data has been received, it calls the ACC function proxy execution unit 233 with the received list of multiple uncombined data areas as an argument (see symbol gg in FIG. 2).

[0078] In the <execution pattern>, the ACC function proxy execution unit 233 receives, as input, a list of accelerator function execution data from the ACC-NIC common data parser 232. Based on the input multiple unbound accelerator execution data, the ACC function proxy execution unit 233 extracts data transfer contents to ACC excluding function IDs, final bits, etc., and issues instructions to the distributed data ACC batch transfer instruction unit 234. These processes are executed by only referencing the unbound data without involving copy processing. In the <execution pattern>, the ACC function proxy execution unit 233 passes, as output, a list of data to be transferred to the accelerator 212 from among the accelerator function execution data to the distributed data ACC batch transfer instruction unit 234 (see symbol hh in FIG. 2).

[0079] The distributed data ACC batch transfer instruction unit 234 receives as input a list of data to be transferred from the ACC function proxy execution unit 233. Based on the input list of multiple uncombined data areas, the distributed data ACC batch transfer instruction unit 234 instructs the distributed data transfer function (Scatter-Gather DMA) of the accelerator 212 to transfer multiple areas to the accelerator 212 in a batch without combining data (see symbol ii in FIG. 2). This ACC batch transfer access to the accelerator 212 is performed at high speed using Polling (see the oval in FIG. 2).

[0080] Off-road return trip In the <transmission pattern>, the accelerator 212 receives, as an input, “ACC instruction data” from the distributed data ACC batch transfer instruction unit 234. In the <transmission pattern>, the accelerator 212 passes, as an output, “execution result” to the ACC function & return value data acquisition unit 235 (see symbol jj in FIG. 2).

[0081] In response to a function call from the ACC function proxy execution unit 233, the ACC function / return value data acquisition unit 235 responds to the ACC function proxy execution unit 233 with the execution result (return value) acquired from the accelerator 212 (see symbol kk in FIG. 2). In the <result response pattern>, the ACC function proxy execution unit 233 sends the "function name and function execution result" as output to the response data transmission unit 236 (see symbol II in FIG. 2).

[0082] The response data transmission unit 236 receives as input a "function name and arguments" from the ACC function proxy execution unit 233. The response data transmission unit 236 converts the input function name and function execution result into data as a UDP / IP packet and its payload. The response data transmission unit 236 passes as output a "transmission packet" to the NIC 211 of the server HW 210 (see symbol mm in FIG. 2). The NIC 211 passes the "transmission packet" to the NIC 111 of the client HW 110 connected via NW 1.

[0083] The NIC 111 of the client 100 receives the packet from the NIC 211 of the server HW 210, and passes it to the polling data transmission / data acquisition unit 134 (see reference symbol nn in FIG. 2). The polling data transmission / data acquisition unit 134 accepts a "received packet" from the NIC 111 as a receiving pattern input, and passes the "received packet" to the function / argument data parsing unit 135 as a receiving pattern output (see reference symbol oo in FIG. 2).

[0084] The function and argument data parsing unit 135 deserializes the “received packet” input from the server 200 according to a predetermined protocol format, obtains the function name and execution result, and passes it to the ACC function proxy response unit 136 (see symbol pp in Figure 2).

[0085] The ACC function proxy response unit 136 receives, as input, the "function name and execution result" from the function and argument data parsing unit 135. The ACC function proxy response unit 136 passes, as output, a "return value" to the user application unit 131 (see symbol qq in FIG. 2). The user application unit 131 receives the function execution result from the ACC function proxy response unit 136 .

[0086] [Offload processing of the computation offload system 1000] Next, the offload processing of the computation offload system 1000 will be described with reference to the control sequence of FIG. 5 and the flowcharts of FIGS. 6 to 8 and 10. FIG.

[0087] <Control sequence> FIG. 5 is a control sequence showing the offload processing of the computation offload system 1000 of FIGS. As shown in FIG. 5, client 100 (see FIG. 1 and FIG. 2) executes offload processing during transmission (S100; see FIG. 6) and transmits the processing result as data to server 200 (see FIG. 1 and FIG. 2) via NW1 (see FIG. 1 and FIG. 2) (S1; see data transmission sequence).

[0088] The server 200 receives the data transmitted from the client 100 via the NW1, and executes the offload process in the server (S200; see FIGS. 7A, 7B, and 8).

[0089] The server 200 transmits the ACC function processing result to the client 100 via the NW1 (S2; see data transmission sequence).

[0090] The client 100 executes offload processing during reception (S300; see FIG. 10).

[0091] <Offload processing when sending from client 100> FIG. 6 is a flowchart showing the offload process (the process of S100 in FIG. 5) during transmission by the client 100 of the computation offload system 1000 in FIGS. In step S101, the user application unit 131 of the user land APL 130 performs an API call and outputs a "function name and arguments."

[0092] In step S102, the ACC function proxy reception unit 132 of the user land APL 130 receives the “function name and arguments” from the user application unit 131, and passes the “function name and arguments” to the ACC-NIC common data creation unit 133.

[0093] In step S103, the ACC-NIC common data creation unit 133 of the user land APL 130 converts the input function name and arguments into data as an L2 frame and its payload that can be transmitted by the NIC. Specifically, the ACC-NIC common data creation unit 133 serializes the input function name and multiple arguments according to a predetermined protocol format and packets them as payloads to convert them into a single piece of data.

[0094] In step S104, the polling data transmission / data acquisition unit 134 of the userland APL 130 accepts "transmission data" from the ACC-NIC common data creation unit 133 as a transmission pattern input, and passes the "transmission data" to the NIC 111 of the client HW 110 as a transmission pattern output.

[0095] In step S105, the NIC 111 transmits a packet to the server HW 210 connected via the NW1.

[0096] <Offload processing of server 200> 7A and 7B are flowcharts showing the offload process (the process of S200 in FIG. 5) of the server 200 of the computation offload system 1000 in FIG. 1 and FIG. 2. In FIG. In step S201, the NIC 211 of the server HW 210 receives a packet as an input from the NIC 111 of the client 100 connected via the NW1 in the <reception pattern>.

[0097] In step S202, the ACC offload continuous instruction unit 231 of the userland APL 230 checks for data arrival by polling the NIC 211 of the server HW 210 in a busy loop, and performs reception processing if data has arrived. Then, the ACC offload continuous instruction unit 231 instructs the ACC-NIC common data parse unit 232 to continuously execute parse of the ACC offload processing following that processing.

[0098] In step S203, the ACC-NIC common data parsing unit 232 of the userland APL 230 parses the data received from the ACC offload continuous instruction unit 231 and detects whether it is the last frame of the function execution data divided into multiple parts. Detailed processing of the ACC-NIC common data parsing unit 232 will be described later with reference to the processing flow in FIG. 8 and the data structure diagram in FIG. 9.

[0099] In step S204, ACC-NIC common data parse unit 232 determines whether or not the arrived packet is the final packet. If the arrived packet is not the final packet (S204: No), the process returns to step S202.

[0100] If the packet that arrived in step S204 above is the final packet (S204: Yes), in step S205, the ACC function proxy execution unit 233 of the userland APL 230 extracts the data transfer contents to the ACC, excluding the function ID, final bit, etc., based on the input multiple unbound accelerator execution data, and issues instructions to the distributed data ACC batch transfer instruction unit 234.

[0101] In step S206, the distributed data ACC bulk transfer instruction unit 234 of the user land APL 230 instructs the distributed data transfer function (Scatter-Gather DMA) of the accelerator 212 to batch transfer multiple areas to the accelerator 212 without performing data combination, based on the input list of multiple uncombined data areas.

[0102] In step S207, the accelerator 212 of the server HW 210 performs a specific calculation at high speed based on the input from the CPU. The accelerator 212 is equipped with a scatter-gather DMA and is capable of transferring distributed data on the host memory in a lump.

[0103] In step S208, the ACC function / return value data acquisition unit 235 of the user land APL 230 monitors the completion of the calculation in the accelerator 212 by polling using a busy loop, and when completion is detected, acquires the execution result of the accelerator 212 and parameters indicating the status of the result (execution success, failure, etc.).

[0104] In step S209, in the <result response pattern>, the ACC function proxy execution unit 233 of the user land APL 230 receives, as input, the “execution result” from the ACC function and return value data acquisition unit 235. In the <result response pattern>, the ACC function proxy execution unit 233 passes, as output, the “function name and execution result” to the response data transmission unit 236.

[0105] In step S210, the response data transmission unit 236 of the userland APL 230 creates response data based on the input function name and execution result, and instructs the NIC 111 of the server HW 210 to transmit it.

[0106] In step S211, the NIC 211 of the server HW 210 transmits a packet to the NIC 111 of the client 100 connected via the NW1.

[0107] 8 is a flowchart showing the parsing process of ACC-NIC common data parsing unit 232. This is a detailed processing flow of ACC-NIC common data parsing unit 232 in step S203 of FIG. In step S221, the ACC-NIC common data parsing unit 232 detects the reception of a frame.

[0108] In step S222, ACC-NIC common data parsing unit 232 copies the parsed data. Specifically, ACC-NIC common data parsing unit 232 copies the actual data (subsequent data address storage area 354, argument <1> 355, and argument <2> 356) excluding L2 frame 351, function ID 352, and final data bit 353 of accelerator function / argument data packet 350 in FIG.

[0109] In step S223, ACC-NIC common data parsing unit 232 determines whether or not it is the first arriving frame. If it is the first arriving frame (S223: Yes), the process proceeds to step S225.

[0110] If it is not the first arriving frame (S223: No), in step S224, the ACC-NIC common data parse unit 232 stores the storage address of the currently received frame in the "successive data address storage area" of the data structure for the storage destination of the previous received frame, and proceeds to step S225 (see Figure 9).

[0111] In step S225, ACC-NIC common data parse unit 232 checks the final data bit to determine whether or not it is the final frame (checking the final frame will be described later with reference to FIG. 9). If it is not the final frame (S225: No), the process returns to step S221.

[0112] If it is the final frame (S225: Yes), in step S226 the ACC-NIC common data parsing unit 232 notifies the ACC offload continuity instruction unit 231 and ends the processing of this flow.

[0113] FIG. 9 is a diagram of the data structure in memory including the subsequent data address storage area of ​​the accelerator function / argument data packet. The example of Fig. 9 shows the actual data of three frames (subsequent data address storage area, argument <1>, argument <2>) of accelerator function·argument data packet 350 of Fig. 3. The frame on the left side of Fig. 9 has subsequent data address storage area 354 specified by address A, and has a following area 1 (here, 1 / 2 of argument <1> 355). Subsequent data address storage area 354 is an area in which accelerator 212 records the address of subsequent data, and here, address B specifying subsequent data address storage area 354 of the next frame is stored.

[0114] 9, the subsequent data address storage area 354 is specified by address B, and has a subsequent area 1 (here, 2 / 2 of argument <1> 355). In the subsequent data address storage area 354 of the central frame in Fig. 9, an address C that specifies the subsequent data address storage area 354 of the next frame is stored.

[0115] 9, the succeeding data address storage area 354 is specified by address C, and has a following area 1 (here, 1 / 2 of argument <2> 356). Since the frame on the right side of Fig. 9 is the final frame, the succeeding data address storage area 354 does not store an address that specifies the succeeding data address storage area 354 of the next frame (successive data address storage area: empty).

[0116] The ACC-NIC common data parsing unit 232 (FIGS. 1 and 2) checks the final data bit to determine whether or not it is the final frame (step S225 in FIG. 8). If the third frame is the final frame, ACC-NIC common data parsing unit 232 stores the three frames in memory in the data structure shown in FIG. The distributed data ACC batch transfer instruction unit 234 (FIGS. 1 and 2) reads such an inter-frame data structure and transfers it to the accelerator 212 in a batch.

[0117] <Offload processing when client 100 receives> FIG. 10 is a flowchart showing the offload process (the process of S300 in FIG. 5) at the time of reception by the client 100 of the computation offload system 1000 in FIGS. In step S301, the NIC 111 of the client 100 receives a packet from the NIC 211 of the server HW 210 connected via the NW 1.

[0118] In step S302, the polling data transmission and data acquisition unit 134 of the user land APL 130 accepts the “received packet” from the NIC 111, and passes the “received packet” to the function and argument data parsing unit 135.

[0119] In step S303, the function / argument data parsing unit 135 of the user land APL 130 deserializes the input packet data (the “received packet”) to obtain the “function name / execution result” from the input data and passes it to the ACC function proxy response unit 136.

[0120] In step S304, the ACC function proxy response unit 136 of the user land APL 130 accepts the “function name and execution result” from the function and argument data parsing unit 135, and passes the “return value” to the user application unit 131 as an output.

[0121] In step S305, the user application unit 131 of the user land APL 130 accepts the function execution result from the ACC function proxy response unit 136.

[0122] [Variations] <Variation 1> 1 and 2, the computation offload system 1000 is configured as a bare metal configuration without virtualization in the server side application, but it can also be configured as a container / VM (Virtual Machine) configuration with virtualization. The following will be described with reference to FIGS. 11 and 12.

[0123] Fig. 11 is a schematic diagram of a computation offload system according to <Modification 1> of an embodiment of the present invention. Since there is no change to the client 100 in Fig. 1 and Fig. 2, it is omitted from the illustration, and only the server 300 is illustrated. The same components and operation explanation symbols as those in Fig. 1 and Fig. 2 are assigned the same reference numerals, and explanations of overlapping parts are omitted. As shown in FIG. 11, a computation offload system 1000A according to the first modification includes a server 300. The server 300 includes a server HW 210, a host OS 320 having an OS kernel 321, a VMM (virtual machine monitor) 330, and a guest OS 340. The guest OS 340 includes a userland APL 230 and an OS kernel 240. The userland APL 230 includes an ACC offload continuous instruction unit 231, an ACC-NIC common data parsing unit 232, an ACC function proxy execution unit 233, a distributed data ACC batch transfer instruction unit 234, and a response data transmission unit 236.

[0124] The operation of the computation offload system 1000A configured as described above will now be described. Offload outbound (server side only) In the <reception pattern>, the NIC 211 of the server HW 210 passes a "received packet" as output to the ACC offload continuous instruction unit 231 by NIC pass-through (see the dashed oval in FIG. 11) via a NIC driver (not shown) (see the symbol rr in FIG. 11). The relationship between the ACC offload continuous instruction unit 231 and the NIC 211 is such that the actual NIC 211 is directly accessed by NIC pass-through. Note that there are two other examples of a relationship between the ACC offload continuous instruction unit 231 and the NIC 211 where the access is via a virtual IF prepared by a virtual machine, such as virtio.

[0125] The ACC offload continuous instruction unit 231 confirms the arrival of data by polling the NIC 211 of the server HW 210 in a busy loop, and if data has arrived, it performs receiving processing and instructs the ACC-NIC common data parse unit 232 to continuously execute the parsing of the ACC offload processing following that processing (see symbol ss in Figure 11).

[0126] The ACC-NIC common data parsing unit 232 parses the data received from the ACC offload continuous instruction unit 231 and detects whether it is the last frame of the function execution data divided into multiple parts. When the ACC-NIC common data parsing unit 232 detects that the final data has been received, it calls the ACC function proxy execution unit 233 with the received list of multiple uncombined data areas as an argument (see symbol tt in FIG. 11).

[0127] In the <execution pattern>, the ACC function proxy execution unit 233 receives, as input, a list of accelerator function execution data from the ACC-NIC common data parser 232. Based on the input multiple unbound accelerator execution data, the ACC function proxy execution unit 233 extracts data transfer contents to ACC excluding function IDs, final bits, etc., and issues instructions to the distributed data ACC batch transfer instruction unit 234. In these processes, the unbound data is executed by reference only, without copy processing. In the <execution pattern>, the ACC function proxy execution unit 233 passes, as output, to the distributed data ACC batch transfer instruction unit 234 a list of data to be transferred to the accelerator 212 from among the accelerator function execution data.

[0128] The distributed data ACC batch transfer instruction unit 234 receives as input a list of data to be transferred from the ACC function proxy execution unit 233. Based on the input list of multiple uncombined data areas, the distributed data ACC batch transfer instruction unit 234 instructs the distributed data transfer function (Scatter-Gather DMA) of the accelerator 212 to transfer multiple areas to the accelerator 212 in a batch without combining data (see symbol uu in FIG. 11). This ACC batch transfer access to the accelerator 212 is performed at high speed using Polling (see the oval in FIG. 11).

[0129] Offload return route (only server side explanation) In the <transmission pattern>, the accelerator 212 receives "ACC instruction data" from the distributed data ACC batch transfer instruction unit 234 as input. In the <transmission pattern>, the accelerator 212 passes "execution results" to the response data transmission unit 236 by ACC pass-through (see the dashed oval in FIG. 11) as output (see symbols vv in FIG. 11). The relationship between the response data transmission unit 236 and the NIC 211 is such that the actual accelerator 212 is directly accessed by ACC pass-through.

[0130] The response data transmission unit 236 converts the input function name and function execution result into data as a UDP / IP packet and its payload. The response data transmission unit 236 passes a "transmission packet" as an output to the NIC 211 of the server HW 210 (see the symbol ww in FIG. 11).

[0131] The computation offload system 1000A according to <Modification 1> can be applied to a VM configuration involving virtualization.

[0132] <Variation 2> Fig. 12 is a schematic diagram of a computation offload system according to <Modification 2> of an embodiment of the present invention. The same components and operation explanation symbols as those in Fig. 1, Fig. 2 and Fig. 11 are assigned the same reference numerals, and explanations of overlapping parts will be omitted. As shown in FIG. 12, a computation offload system 1000B according to the second modification includes a server 400. The server 400 includes a server HW 210, a host OS 320 having an OS kernel 321, and a container 440. The container 440 comprises an ACC offload continuous instruction unit 231 , an ACC-NIC common data parsing unit 232 , an ACC function proxy execution unit 233 , a distributed data ACC batch transfer instruction unit 234 , and a response data transmission unit 236 .

[0133] The operation of the computation offload system 1000B is similar to that of the computation offload system 1000A of FIG. 11, so the same reference numerals are used and the description will be omitted. The ACC offload continuous instruction unit 231 and the NIC 211 have a relationship in which they directly access the actual NIC 211 by NIC pass-through (see the dashed ellipse in FIG. 12). As another example, there are two examples in which the ACC offload continuous instruction unit 231 and the NIC 211 have a relationship in which they access each other via a virtual NIC via a Linux bridge or the like.

[0134] The computation offload system 1000B according to the second modification can be applied to a container involving virtualization.

[0135] <Modification 3> In this embodiment, a single client program performs offloading to a single server, but these may be offloaded in parallel. Specifically, the following two patterns are expected: 1: Multiple client programs offload data in parallel to a single server. 2: A single program offloads data in parallel to a single server.

[0136] Here, the mechanism for realizing parallel execution can take the form of simultaneously executing multiple ACC offload continuous instruction unit 231, ACC-NIC common data parsing unit 232, ACC function proxy execution unit 233, distributed data ACC batch transfer instruction unit 234, ACC function / return value data acquisition unit 235 and response data transmission unit 236 on the server side.

[0137] [Hardware configuration] The server 200 of the computation offload system 1000 according to the above embodiment is realized by a computer 900 having a configuration as shown in FIG. 13, for example. FIG. 13 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the server 200. As shown in FIG. The server 200 includes a CPU 901, a RAM 902, a ROM 903, a HDD 904, an accelerator 905, an input / output interface (I / F) 906, a media interface (I / F) 907, and a communication interface (I / F: Interface) 908. The accelerator 905 corresponds to the accelerator 212 in FIGS.

[0138] The accelerator 905 is an accelerator (device) 212 (FIGS. 1 and 2) that processes at least one of data from the communication I / F 908 and data from the RAM 902 at high speed. Note that the accelerator 905 may be of a type that returns the execution result to the CPU 901 or RAM 902 after executing the processing from the CPU 901 or RAM 902 (look-aside type). On the other hand, the accelerator 905 may be of a type that is inserted between the communication I / F 908 and the CPU 901 or RAM 902 and performs processing (in-line type).

[0139] The accelerator 905 is connected to an external device 915 via a communication I / F 908. The input / output I / F 906 is connected to an input / output device 916. The media I / F 907 reads and writes data from a recording medium 917.

[0140] The CPU 901 operates based on a program stored in the ROM 903 or the HDD 904, and executes a program (also called an application or its abbreviation, an app) loaded into the RAM 902, thereby controlling each part of the server 200 shown in Figures 1 and 2. This program can also be distributed via a communication line, or recorded on a recording medium 917 such as a CD-ROM and distributed. The ROM 903 stores a boot program executed by the CPU 901 when the computer 900 is started, programs that depend on the hardware of the computer 900, and the like.

[0141] The CPU 901 controls an input / output device 916 consisting of an input unit such as a mouse and a keyboard, and an output unit such as a display and a printer, via an input / output I / F 906. The CPU 901 acquires data from the input / output device 916 via the input / output I / F 906, and outputs generated data to the input / output device 916. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 901.

[0142] The HDD 904 stores programs executed by the CPU 901 and data used by the programs, etc. The communication I / F 908 receives data from other devices via a communication network (e.g., a NW (Network)) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0143] The media I / F 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 a program related to a target process from the recording medium 917 onto the RAM 902 via the media I / F 907, and executes the loaded program. The recording medium 917 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase change rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a conductive memory tape medium, a semiconductor memory, or the like.

[0144] For example, when the computer 900 functions as the server 200 configured as one device according to this embodiment, the CPU 901 of the computer 900 executes a program loaded onto the RAM 902 to realize the functions of the server 200. Furthermore, the data in the RAM 902 is stored in the HDD 904. The CPU 901 reads and executes a program relating to a target process from a recording medium 917. Alternatively, the CPU 901 may read a program relating to a target process from another device via a communication network.

[0145] [effect] As described above, the computation offload system 1000 (FIGS. 1 and 2) comprises a client 100 and a server 200 connected via a network 1 and a NIC 212, in which the client 100 offloads specific processing of an application to an accelerator 212 arranged in the server 200 for computation, and the server 200 has a userland APL 230 that bypasses the OS 220 and cooperates with the accelerator 212, and the userland APL 230 has an ACC-NIC common data parsing unit 232 that parses received data that has a common input data format for the ACC-used function and a common NIC received data format.

[0146] In this way, the input data format of the ACC use function and the NIC reception data format are common, resulting in a configuration that eliminates the overhead of mutual conversion.

[0147] This makes it possible to reduce the amount of data binding and conversion processing when the server offloads distributed received data to the accelerator 212, and by reducing the amount of data binding and conversion processing, it is possible to achieve low latency. It is possible to realize a remote offloading method that achieves both transparency that does not require any changes to the application that uses the accelerator 212 and real-time performance.

[0148] The computational processing offload system 1000 (Figures 1 and 2) is characterized by having a distributed data ACC bulk transfer instruction unit 234 that instructs the accelerator 212 to bulk transfer data received as packets by the ACC-NIC common data parsing unit 232 to the accelerator 212 while keeping the data in a distributed state in the user land memory.

[0149] As a result, the distributed received data is transferred to the ACC device in one go while still remaining distributed in memory, making the NIC reception-ACC data transfer zero-copy and resulting in a configuration with no data combination overhead. The memory area to be accessed is allocated only to the userland APL230, reducing interrupts between the userland APL and the OS and in communication with devices (ACC / NIC). This reduction in interrupts makes it possible to achieve low latency.

[0150] In the computation offload system 1000 (FIGS. 1 and 2), the distributed data ACC batch transfer instruction unit 234 is characterized in that it instructs the distributed data transfer function (Scatter-Gather DMA) of the accelerator 212 to batch transfer multiple areas to the accelerator 212 without performing data combination, based on an input list of multiple uncombined data areas.

[0151] This allows the distributed received data to be transferred to the ACC device in one go while still remaining distributed in memory, making the NIC receive-ACC data transfer zero-copy and reducing data merge overhead.

[0152] The computational processing offload system 1000 (Figures 1 and 2) is characterized in that it has an ACC offload continuous instruction unit 231 that confirms data arrival by polling the NIC 211 of the server HW 210 in a busy loop, and if data has arrived, performs reception processing, and instructs the ACC-NIC common data parse unit 232 to continuously execute ACC offload processing parsing following that processing.

[0153] In this way, the ACC offload continuous instruction unit 231 performs ACC / NIC access by Busy Polling, and detects data arrival and transmission without interrupts. Furthermore, after detection, the ACC offload continuous instruction unit 231 executes the ACC offload function in the same context and the same CPU core. Here, processing in the same context means that processing is completed by the same single CPU core on the CPU without the intervention of other processing due to an interrupt.

[0154] This enables a series of processes from packet processing to ACC offloading to be executed continuously by a single CPU core, achieving low jitter.

[0155] Furthermore, among the processes described in the above embodiments and modifications, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by a known method. In addition, the information including the processing procedures, control procedures, specific names, various data, and parameters shown in the above documents and drawings can be changed arbitrarily unless otherwise specified. In addition, each component of each device shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads, usage conditions, etc.

[0156] In addition, the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. In addition, the above-mentioned configurations, functions, etc. may be realized by software for a processor to interpret and execute a program that realizes each function. Information on the programs, tables, files, etc. that realize each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC (Integrated Circuit) card, SD (Secure Digital) card, or optical disk. [Explanation of symbols]

[0157] 1 Network (NW) 100 clients 110 Client Hardware 111,211 NIC 120,220 OS 130,230 Userland APL 131 User Application Part 132 ACC Function Delegate Reception 133 ACC-NIC Common Data Creation Department 134 Polling data transmission and data acquisition unit 135 Function and Argument Data Parsing Section 136 ACC Function Proxy Response Part 200 Servers 210 Server HW 212 Accelerator 231 Polling data acquisition ACC offload continuous instruction part (ACC offload continuous instruction part) 232 ACC-NIC Common Data Parsing Department 233 ACC Function Delegate Execution Unit 234 Distributed Data ACC Bulk Transfer Instruction 235 ACC function return value data acquisition section 236 Response data transmission unit 350 Accelerator Function Argument Data Packet 354,364 Subsequent data address storage area 360 Accelerator Function Return Packet 1000, 1000A, 1000B Calculation Processing Offload System

Claims

1. A computation offload system comprising: a client; and a server connected via a network and a network interface card (NIC), the client offloading a specific process of an application to an accelerator arranged on the server for computation, The server, a userland application that bypasses the OS and interacts with the accelerator; The userland application It has an ACC-NIC common data parsing unit that parses received data that has a common input data format for ACC (accelerator)-used functions and a common NIC received data format. A computation offload system comprising:

2. A distributed data ACC batch transfer instruction unit instructs the accelerator to batch transfer the data received by the ACC-NIC common data parse unit as packets while keeping the data in a distributed state on a user land memory to the accelerator.

2. The computation offload system according to claim 1.

3. The distributed data ACC batch transfer instruction unit, Based on the input list of the uncombined multiple data areas, a distributed data transfer function of the accelerator is instructed to transfer data of the multiple areas to the accelerator in a batch without combining data.

3. The computation offload system according to claim 2.

4. The ACC offload continuous instruction unit performs data arrival confirmation by polling the NIC in a busy loop, and when data has arrived, performs reception processing, and instructs the ACC-NIC common data parsing unit to continuously execute parsing of the ACC offload processing following the processing.

2. The computation offload system according to claim 1.

5. A computation offloading method for a computation offloading system including a client and a server connected via a network and a network interface card (NIC), the client offloading a specific process of an application to an accelerator arranged on the server for computation, the method comprising: The server, a userland application that bypasses the OS and interacts with the accelerator; The userland application: Execute a step of parsing received data that has a common input data format for an ACC (accelerator) function and a NIC received data format.

13. A computation offloading method comprising:

6. A computation offload system includes a client and a server connected via a network and a network interface card (NIC), the client offloads a specific process of an application to an accelerator arranged on the server for computation, the server having a userland application that bypasses an OS and cooperates with the accelerator, and the server is provided with: An ACC-NIC common data parsing procedure for parsing received data that has a common input data format for an ACC (accelerator)-used function and a common NIC received data format; A program for executing the above.

Images