Computational processing offload system and computational processing offload method

Abstract

This NIC hardware (300) comprises: an accelerator function / argument data parsing unit (310) that de-serializes, according to the format of a predetermined protocol, packet data inputted from a client side, thereby acquiring a function name / a plurality of arguments; an accelerator function / return value data packetizing unit (330) that serializes, according to the format of a predetermined protocol, and further packetizes, as payload, the function name and arguments inputted from an accelerator; and a data transferring unit (320) that transfers the data of the accelerator function / argument data parsing unit to a server.

Description

[Technical field]

[0001] The present invention relates to a computation offload system and a computation offload method. [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 a server at a remote site (such as a data center located near the user) via a network (hereinafter referred to as NW) (see non-patent document 1).

[0003] FIG. 15 is a diagram illustrating the device configuration of the offload system via the NW. As shown in FIG. 15, 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 is a terminal that is powered by a battery or the like and has limited computing power. 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 ACC-using IF 42, and middleware 43. The ACC-using IF 42 is an ACC (Accelerator: calculation accelerator device)-using IF specification made up of OpenCL (Open Computing Language) or the like.

[0004] The client 10 does not include a calculation accelerator device (hereinafter, referred to as 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 (Application Programming Interface) for ACC access. The client application unit 41 running 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. 15, 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 client terminal (client 10) does not require special hardware such as a NIC (versatility). Requirement 3: The overhead in ACC calculation offload via NW1 must be small (low latency).

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

[0010] Fig. 16 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. 16, the same components as those in Fig. 15 are given the same reference numerals. The solid arrow in FIG. 16 indicates an off-road outbound route, and the dashed arrow in FIG. 16 indicates an off-road return route. As shown in FIG. 16, the accelerator standard IF offload system includes a client 10 and a server 50 connected to the client 10 via a NW1. 16 includes a client HW 20, an OS 30, and an application (hereinafter, referred to as APL as appropriate) 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 . The APL 40 has a client application unit 41 , an ACC function proxy reception unit 44 , an ACC function and return value packetization unit 45 , an ACC function and argument data parsing unit 46 , and an ACC function proxy response unit 47 .

[0011] The server 50 shown in FIG. 16 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. It 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. 16). 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. 16).

[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. 16). 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. 16). 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. 16) 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. 16). 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. 16).

[0015] The ACC function proxy execution unit 83 offloads (see symbol h in FIG. 16) 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. 16). 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. 16). 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. 16). 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 symbol l in FIG. 16). 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. 16) 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. 16). 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. 16). 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. 16).

[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 August 4, 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. 16, 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 was made in consideration of this background, and its objective is to reduce latency by eliminating the overhead in the interaction between the OS's "protocol stack" and the "ACC functions and argument data." [Means for solving the problem]

[0022] In order to solve the above-mentioned problems, the present invention provides a computation offload system comprising a client and a server connected via a network and a NIC (Network Interface Card) functional unit, in which the client offloads specific processing of an application to an accelerator arranged on the server for computation, the NIC functional unit comprising an accelerator function and argument data parsing unit that deserializes packet data input from the client side in accordance with a predetermined protocol format and acquires a function name and multiple arguments, a data transfer unit that transfers the data deserialized by the accelerator function and argument data parsing unit to the server, and an accelerator function and return value data packetization unit that serializes the function name and arguments input from the accelerator in accordance with a predetermined protocol format and packetizes them as a payload. and further comprising an ACC argument recording unit that receives and records data to be transferred from the data transfer unit to the server, an ACC function execution timing recording unit that records whether the ACC argument and ACC function recorded in the ACC argument recording unit are in an executable state, an ACC function execution timing confirmation unit that refers to the ACC function execution timing recording unit and detects that the offload function execution unit is able to execute the ACC function based on the data recorded in the ACC argument recording unit, and an offload function execution unit that executes an accelerator function based on an input function name and argument and shares the result with the accelerator. The present invention provides a computation offload system characterized by the above. Effect of the Invention

[0023] According to the present invention, it is possible to reduce latency by eliminating the overhead involved in linking the OS's "protocol stack" and the "ACC function / argument data". [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] 1 is a diagram showing an example of the configuration of an ACC function / argument data packet of the computation offload system according to an embodiment of the present invention. FIG. [Figure 4] FIG. 2 is a diagram illustrating an example of the configuration of an accelerator function / return value packet of the computation offload system according to the embodiment of the present invention. [Diagram 5] FIG. 2 is a functional block diagram of NIC hardware of the computation offload system according to the embodiment of the present invention. [Figure 6] FIG. 1 is a diagram for explaining an overview of middleware processing in a receiving section of a client of the existing technology. [Figure 7] FIG. 2 is a diagram illustrating an overview of NIC hardware processing in the computation offload system according to the embodiment of the present invention. [Figure 8] 4 is a control sequence showing an offload process of the computation offload system according to the embodiment of the present invention. [Figure 9] 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 10] 11 is a flowchart showing an offload process of a NIC hardware server of the computation offload system according to the embodiment of the present invention. [Figure 11] 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 12] FIG. 2 is a schematic configuration diagram of a computation offload system according to <Modification 1> of an embodiment of the present invention. [Figure 13] FIG. 11 is a schematic configuration diagram of a computation offload system according to <Modification 2> of an embodiment of the present invention. [Figure 14] FIG. 2 is a hardware configuration diagram illustrating an example of a computer that realizes a function of a client of the computational processing offload system according to the embodiment of the present invention. [Figure 15] FIG. 1 is a diagram illustrating the device configuration of an offload system via a network. [Figure 16] 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 same components as those in FIG. 15 and FIG. 16 are given the same reference numerals. The offload processing flow of FIG. 2 will be described in detail in the operation description. As shown in Figures 1 and 2, the computational processing offload system 1000 includes a client 100, a server 200 connected to the client 100 via a NW1 and NIC hardware 300, and a NIC hardware 300 (NIC function unit) which is a NIC function unit provided on the server 200 side. In particular, the computation offload system 1000 is characterized by including NIC hardware 300 as a server-side NIC. In the computation offload system 1000, the client 100 offloads specific processing of an application to an accelerator 205 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 NIC hardware that realizes a network interface. In the <transmission pattern>, the NIC 111 accepts, as an input, a "transmission packet" from the packet processing inline insertion unit 121 via the NIC driver unit 122. In the <transmission pattern>, the NIC 111 passes, as an output, a "transmission packet" to the NIC hardware 300 connected via the NW1. In the <reception pattern>, the NIC 111 accepts, as input, a "reception packet" from the server 200 connected via the NIC hardware 300 and the NW 1. In the <reception pattern>, the NIC 111 passes, as output, the "reception packet" to the packet processing inline insertion unit 121 via the NIC driver unit 122.

[0028] 《OS120》 The OS 120 includes a packet processing inline insertion unit 121 and a NIC driver unit 122 .

[0029] <Packet processing inline insertion unit 121> The packet processing inline insertion unit 121 is a transmission / reception function that exchanges input packet data ("transmission packets") with a device driver (NIC driver unit 122) without going through an existing protocol stack. The packet processing inline insertion unit 121 corresponds to, for example, a high-speed communication mechanism with a driver such as XDP / eBPF of Linux (registered trademark).

[0030] The packet processing inline insertion unit 121 exchanges data between the ACC function / argument data packet generation unit 133 and the ACC function / response data parsing unit 134 of the user land APL 130 and the NIC driver unit 122 that harvests data from the NIC 111 without going through a specified protocol stack.

[0031] In the <transmission pattern>, the packet processing inline insertion unit 121 receives, as an input, a “transmission packet” from the ACC function & argument data packet generation unit 133 of the user land APL 130. In the <transmission pattern>, the packet processing inline insertion unit 121 passes, as an output, the “transmission packet” to the NIC driver unit 122.

[0032] In the <reception pattern>, the packet processing in-line insertion unit 121 receives a "received packet" as input from the NIC driver unit 122. In the <reception pattern>, the packet processing in-line insertion unit 121 passes the "received packet" as output to the ACC function & response data parsing unit 134.

[0033] <NIC driver unit 122> The NIC driver unit 122 is a device driver that abstracts the interfaces specific to each NIC type. The NIC driver unit 122 is composed of ordinary off-the-shelf device drivers. In the <transmission pattern>, the NIC driver unit 122 receives a "transmitted packet" as input from the packet processing in-line insertion unit 121. In the <transmission pattern>, the NIC driver unit 122 passes the "transmitted packet" as output to the NIC 111.

[0034] In the <reception pattern>, the NIC driver unit 122 receives a "received packet" as input from the NIC 111. In the <reception pattern>, the NIC driver unit 122 passes the "received packet" as output to the packet processing in-line insertion unit 121.

[0035] 《Userland APL 130》 The Userland APL 130 includes a user application unit 131, an ACC function proxy reception unit 132, an L3 / L4 protocol & ACC function & argument data packet generation unit (hereinafter referred to as the ACC function & argument data packet generation unit) 133, an L3 / L4 protocol & ACC function & response data parsing unit (hereinafter referred to as the ACC function & response data parsing unit) 134, and an ACC function proxy response unit 135.

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

[0037] <ACC function proxy reception unit 132> The ACC function proxy reception unit 132 is realized as middleware having an interface compatible with the standard API. The ACC function proxy reception unit 132 has an interface equivalent to the standard API such as OpenCL and receives API calls from the user. The ACC function proxy reception unit 132 is prepared as a binary file separate from the standard user application and is realized in the form of a "dynamic library" in which dynamic link calls are made at the time of execution. The ACC function proxy reception unit 132 receives the "function name · arguments" from the user application unit 131 as input. The ACC function proxy reception unit 132 passes the "function name · arguments" to the ACC function · argument data packet generation unit 133 as output. The ACC function proxy reception unit 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.

[0038] <Schematic description of the ACC function · argument data packet generation unit 133 and the ACC function · response data parsing unit 134> Here, the ACC function · argument data packet generation unit 133 and the ACC function · response data parsing unit 134 will first be described schematically (detailed descriptions will be given later).

[0039] (1) The ACC function and argument data packet generator 133 is characterized in that it is a single dedicated function that combines the function and return value packetizer 45 on the APL 40 side and the L4 / L3 protocol stack unit 31 of the OS 30 in the accelerator standard IF offload system of the conventional technology shown in Fig. 16. The single dedicated function is a single function that combines each protocol processing function of the OS kernel 500 shown in Fig. 6, such as the Soft IRQ handler processing, L2, L3 protocol processing, packet reaping processing (NAPI), Soft IRQ handler processing, L4 protocol processing, and ACC function parsing processing, as described in the existing technology shown in Fig. 6 below. In the conventional technology, each protocol processing function exists in a plurality of functions, but in this embodiment, the ACC function and argument data packet generator 133 is combined into a single dedicated function.

[0040] As with the ACC function and argument data packet generation unit 133, the ACC function and response data parsing unit 134 is characterized in that it combines the function and argument data parsing unit 46 on the APL 40 side and the L4 / L3 protocol stack unit 31 of the OS 30 in the conventional accelerator standard IF offload system shown in FIG. 16 into a single dedicated function.

[0041] As described above, in the conventional technology, multiple protocol processes (L2, L3 protocol processing, packet harvesting processing (NAPI), L4 protocol processing, ACC function parsing processing, etc.) exist, and processing for selecting a protocol stack such as L4 / L3 was required. In contrast, the computation processing offload system 1000 is characterized by being equipped with an ACC function / argument data packet generation unit 133 and an ACC function / response data parsing unit 134, which have a single dedicated function, thereby eliminating the multiple protocol processes required in the conventional technology and providing dedicated functions. As a result, the computation offload system 1000 can reduce the number of selections and copies on the client 100 side through data linkage, thereby reducing overhead and increasing speed.

[0042] <ACC Function and Argument Data Packet Generation Unit 133> The ACC function and argument data packet generation unit 133 converts the input function name and arguments into data in the form of UDP / IP packets and their payloads. The ACC function and argument data packet generation unit 133 serializes the function name and arguments input from the application side according to the format of a predetermined protocol, and packetizes them as a payload to make them into single data. The ACC function and argument data packet generation unit 133 receives "function name and arguments" from the ACC function proxy reception unit 132 as input. The ACC function and argument data packet generation unit 133 passes "transmission packets" to the packet processing in-line insertion unit 121 as output.

[0043] Here, the L3 / L4 protocol may be other than TCP / IP (Transmission Control Protocol / Internet Protocol), such as one that abolishes part of L3 / L4 and uses 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. Also, when the argument size is large, it may have a function to split into multiple packets. At this time, control data for notifying the final packet shown in FIG. 3 is added to the last packet after splitting.

[0044] <ACC Function and Response Data Parsing Unit 134> The ACC function and response data parsing unit 134 deserializes the packet data input from the server 200 side according to the format of a predetermined protocol and obtains the function name and execution result.

[0045] The ACC function and response data parsing unit 134 deserializes the input packet data to obtain "function name and execution result" from the input data and passes it to the ACC function proxy response unit 135.

[0046] The ACC function response data parsing unit 134 receives the "received packet" from the packet processing in-line insertion unit 121 as input. The ACC function response data parsing unit 134 passes the "function name execution result" to the ACC function proxy response unit 135 as output.

[0047] For the example of the packet format of the ACC function response data parsing unit 134, it conforms to the ACC function data parsing unit 310 described later. Also, when the ACC function response data parsing unit 134 has a function to split into multiple packets, the ACC function data parsing unit 310 described later also has a combining process.

[0048] <ACC function proxy response unit 135> The ACC function proxy response unit 135 is realized as middleware with an IF compatible with the specified API. The ACC function proxy response unit 135 is prepared as a binary file separate from the user application unit 131 and is realized in the "dynamic library format" where dynamic link calling is performed at runtime.

[0049] The ACC function proxy response unit 135 exchanges data with the ACC function data parsing unit 310, the ACC function return value data packetization unit 330, and the NIC driver unit 122 that extracts data from the NIC 111 without going through a predetermined protocol stack.

[0050] The ACC function proxy response unit 135 receives the "function name execution result" from the ACC function response data parsing unit 134 as input. The ACC function proxy response unit 135 passes the "return value" (response data) to the user application unit 131 as output.

[0051] The ACC function proxy response unit 135 may also be in the "static library format" that is linked to the user application at program generation time and executed integrally.

[0052] [Server 200] As shown in FIG. 2, the server 200 includes a server HW 210, an OS 220, and a user land APL 230.

[0053] 《Server HW 210》 As shown in FIG. 2, the server HW 210 includes an accelerator 205 (see also FIG. 1).

[0054] <Accelerator 205> The accelerator 205 is a computing unit hardware that performs specific operations at high speed based on inputs from the CPU. The accelerator 205 corresponds to a GPU / FPGA connected to the server 200. In the <transmission pattern>, the accelerator 205 receives "ACC instruction data" from the data transfer unit 320 as an input. In the <transmission pattern>, the accelerator 205 passes "execution results" to the data transfer unit 320 via each functional unit as an output.

[0055] The accelerator 205 may be an integrated form of a CPU and an accelerator on a single chip, such as a System on Chip (SoC). Note that when the accelerator 205 is not mounted, the offload function execution unit 204 may not exist.

[0056] 《User land APL 230》 As shown in FIG. 2, the user land APL 230 includes an ACC argument recording unit 201, an ACC function execution trigger recording unit 202, an ACC function execution trigger confirmation unit 203, and an offload function execution unit 204 (see also FIG. 1).

[0057] <ACC argument recording unit 201> The ACC argument recording unit 201 records information on the input function name and arguments. The ACC argument recording unit 201 receives and records "transfer target data" from the data transfer unit 320 as an input.

[0058] <ACC function execution trigger recording unit 202> The ACC function execution trigger recording unit 202 records whether the arguments recorded in the ACC argument recording unit 201 are in a complete state and the ACC function is in an executable state. The ACC function execution trigger recording unit 202 receives an execution trigger from the data transfer unit 320 as input, and its state is updated by the data transfer unit 320.

[0059] <ACC function execution trigger confirmation unit 203> The ACC function execution trigger confirmation unit 203 refers to the ACC function execution trigger recording unit 202 and detects that the offload function execution unit 204 has become capable of executing the ACC function based on the data recorded in the ACC argument recording unit 201. The ACC function execution trigger confirmation unit 203 always monitors the ACC function execution trigger recording unit 202 as input and checks whether it is in an executable state. This confirmation method may be either a polling form in which the ACC function execution trigger confirmation unit 203 actively repeats state acquisition and confirmation, or an interrupt form in which it receives a notification when a change occurs.

[0060] <Offload function execution unit 204> The offload function execution unit 204 executes an accelerator function based on the input function name and arguments, and coordinates the results with the accelerator 205. As an embodiment, an existing accelerator utilization runtime such as an OpenCL runtime or a CUDA runtime is assumed.

[0061] In the <execution pattern>, the offload function execution unit 204 receives "function name and arguments" from the ACC argument recording unit 201 as input. In the <execution pattern>, the offload function execution unit 204 passes "ACC instruction data" to the accelerator 205 as output. In the <result response pattern>, the offload function execution unit 204 receives "execution result" from the accelerator 205 as input. In the <result response pattern>, the offload function execution unit 204 passes "function name and function execution result" to the ACC function and return value data packetization unit 330 of the NIC hardware 300 as output.

[0062] [NIC Hardware 300] As shown in FIGS. 1 and 2, the NIC hardware 300 is a NIC unit provided on the server 200 side, and is characterized by including an L3 / L4 protocol·ACC function data parsing unit (hereinafter referred to as the ACC function data parsing unit) 310, a data transfer unit 320, and an L3 / L4 protocol·ACC function·return value data packetization unit (hereinafter referred to as the ACC function·return value data packetization unit) 330.

[0063] <ACC function data parsing unit 310> The ACC function data parsing unit 310 deserializes the packet data input from the client 100 side according to the format of a predetermined protocol, and obtains a function name and a plurality of arguments from the input data. The ACC function data parsing unit 310 instructs the data transfer unit 320 to transfer data to the ACC argument recording unit 201. At this time, when the final packet is detected, the data transfer unit 320 is also instructed to transfer data to the ACC function execution trigger recording unit 202.

[0064] The format of the data to be parsed by the ACC function data parsing unit 310 is shown in FIG. 3. FIG. 3 is a diagram showing a configuration example of the ACC function·argument data packet 400. The ACC function·argument data packet 400 is formatted with an L2 frame (0 to 14 bytes), an L3 header (~34 bytes), an L4 header (~42 bytes), a control bit (~46 bytes), a function ID (~50 bytes), an argument 1 (~54 bytes), and an argument 2 (~58 bytes). The ACC function·argument data packet 400 has a data structure suitable for parsing by the FPGA circuit by setting each data to a fixed length and a fixed position.

[0065] The control bit adds control information of the packet. The ACC function data parsing unit 310 has, for example, a function of dividing into a plurality of packets when the argument size is large. At this time, control data for notifying the final packet is added to the "control bit" of the last divided packet. In addition, the packet format shown in FIG. 3 may include not only function names and arguments but also an ID that can uniquely identify the accelerator to be used.

[0066] Returning to FIGS. 1 and 2, the ACC function data parsing unit 310 receives a "received packet" from the NIC unit 111 of the client 100, which is the communication partner, as input. The ACC function data parsing unit 310 passes the transfer destination (ACC argument recording unit 201) and "function name · argument data" to the data transfer unit 320 as output. Note that when the final packet is detected from the input packet, the data transfer to the ACC function execution trigger recording unit 202 is instructed to the data transfer unit 320.

[0067] The arithmetic processing offloading system 1000 is characterized in that it includes an ACC function data parsing unit 310 having a single dedicated function, eliminating a plurality of protocol processes required in the prior art and specializing. Thereby, the arithmetic processing offloading system 1000 can reduce overhead and achieve high speed by reducing the number of selections and copies through data cooperation on the server 200 side.

[0068] <Data transfer unit 320> The data transfer unit 320 is a data transfer functional unit within the NIC hardware 300, and transfers the input data to the memory area of the host machine. The data transfer unit 320 receives two items, "transfer destination" and "transfer target data", from the ACC function data parsing unit 310 as input. The data transfer unit 320 passes the "transfer target data" to the specified transfer destination as output. As a general example, the DMA (Direct Memory Access) function applies.

[0069] <ACC function · return value data packetization unit 330> The ACC function / return value data packetization unit 330 serializes the function name and arguments input from the accelerator 205 according to a predetermined protocol format, and packets them as payloads. The ACC function / return value data packetization unit 330 is a function that converts the input function name and function execution result into data as a UDP / IP packet and its payload. The ACC function / return value data packetization unit 330 serializes the input function name and function execution result according to a predetermined format, and converts them into a single piece of data.

[0070] FIG. 4 is a diagram showing an example of the configuration of the ACC function / return value packet 450. As shown in FIG. The ACC function / return value packet 450 is the format of the ACC function / return value data of the ACC function / return value data packetization unit 330 .

[0071] The ACC function return value packet 450 is formatted with an L2 frame (0 to 14 bytes), an L3 header (up to 34 bytes), an L4 header (up to 42 bytes), control bits (up to 46 bytes), a function ID (up to 50 bytes), and a return value (up to 54 bytes). The control bit adds control information to the packet. The ACC function / return value data packetization unit 330 has a function for dividing the packet into multiple packets when the argument size is large. In this case, the last divided packet is given control data in the "control bit" to notify that it is the last packet. The packet format shown in FIG. 4 may include not only the function name and arguments, but also an ID that can uniquely identify the accelerator to be used. Furthermore, if the ACC function and return value data packetizing unit 330 has a function for dividing into a plurality of packets, the ACC function and argument data packet generating unit 133 of the user land APL 130 of the client 100 also has a combining process.

[0072] 1 and 2, the ACC function and return value data packetization unit 330 receives, as input, a “function name and arguments” from the offload function execution unit 204. The ACC function and return value data packetization unit 330 passes, as output, a “transmission packet” to the NIC unit 111 of the client 100.

[0073] Like the ACC function and argument data packet generator 133, the ACC function and return value data packetizer 330 may use an L3 / L4 protocol other than UDP (User Datagram Protocol) / IP, such as TCP / IP or SCTP (Stream Control Transmission Protocol) / IP. Also, instead of using both L3 and L4, only L3 may be used. Specifically, a configuration may be considered in which IP is used for L3 and a dedicated protocol defined by the user is used for L4 and above.

[0074] Also, only the L4 protocol may be integrated with the ACC function / return value data packetization unit 330, and the L3 protocol may use a general-purpose protocol stack of the OS.

[0075] As described above, the NIC hardware 300 includes the ACC function data parsing unit 310, the data transfer unit 320, and the ACC function / return value data packetizing unit 330, and has the following features. That is, the ACC function and return value data packetization unit 330 is characterized by being a single dedicated function that is a combination of the ACC function and return value packetization unit 84 on the APL80 side and the L4 / L3 protocol stack unit 71 of the OS70 in the accelerator standard IF offload system of the conventional technology shown in Fig. 16. Similarly, the ACC function data parsing unit 310 is characterized by being a single dedicated function that is a combination of the ACC function and argument data parsing unit 82 on the APL80 side and the L4 / L3 protocol stack unit 71 of the OS70 in the accelerator standard IF offload system of the conventional technology shown in Fig. 16.

[0076] As a result, the computation offload system 1000 can reduce the number of selections and copies on the server 200 side through data linkage, thereby reducing overhead and increasing speed.

[0077] [NIC Hardware 300] Fig. 5 is a functional block diagram of the NIC hardware 300 shown in Fig. 1 and Fig. 2. The NIC hardware 300 in Fig. 5 is an example applied to an NIC functional unit realized using an FPGA (FPGA NIC). As shown in FIG. 5, the NIC hardware (FPGA NIC) 300 includes a PCIe bus conversion unit 302 which transmits and receives data to and from an external host memory unit 301, a packet header analysis unit 311, a last packet monitoring unit 312, a DMA target data extraction unit 321, a DMA transfer packet generation unit 322, a DMA unit (write) 323, an attached header information recording unit 331, a DMA unit (read) 323, a transmission buffer unit 333, a transmission packet generation unit 334, a circuit 303, a MAC circuit (L2 unit) 303, a PHY (L1 unit) 304, and a NIC IF unit (SFP) 305.

[0078] The packet header analysis unit 311 and the last packet monitoring unit 312 constitute the ACC function data parsing unit 310 shown in FIG. 1 and FIG. The DMA target data extraction unit 321, the DMA transfer packet generation unit 322, and the DMA unit (Write) 323 constitute the data transfer unit 320 shown in FIGS. Also, the packet header analysis unit 311, last packet monitoring unit 312, DMA target data extraction unit 321, DMA transfer packet generation unit 322, and DMA unit (Write) 323 together form a <function information receiving function group>.

[0079] The attached header information recording unit 331, the DMA unit (Read) 323, the transmission buffer unit 333, and the transmission packet generating unit 334 constitute the ACC function / return value data packetizing unit 330 shown in Figures 1 and 2. In addition, the attached header information recording unit 331, the DMA unit (Read) 323, the transmission buffer unit 333, and the transmission packet generating unit 334 constitute a <function execution result transmission function group>.

[0080] 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. In describing Fig. 2, the same offload processing flows as those in Fig. 16 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.

[0081] Off-road outbound 2, the ACC function proxy reception unit 132 of the user land APL 130 of the client 100 receives as input a "function name and arguments" from the user application unit 131 (see symbol a in FIG. 2). The ACC function proxy reception unit 132 of the client 100 passes as output the "function name and arguments" to the ACC function and argument data packet generation unit 133 of the OS 120 (see symbol b in FIG. 2).

[0082] The ACC function / argument data packet generator 133 of the OS 120 receives as input a "function name and arguments" from the ACC function proxy reception unit 132 (see symbol b in FIG. 2). The ACC function / argument data packet generator 133 converts the input function name and arguments into data as a UDP / IP packet and its payload. The ACC function / argument data packet generator 133 serializes the input function name and multiple arguments according to a predetermined format and converts them into a single piece of data. The ACC function / argument data packet generator 133 passes a "transmission packet" as output to the packet processing inline insertion unit 121 (see symbol c in FIG. 2).

[0083] In the <transmission pattern>, the packet processing inline insertion unit 121 of the OS 120 receives a "transmission packet" as input from the ACC function & argument data packet generation unit 133. The packet processing inline insertion unit 121 exchanges the input packet data with the device driver without going through an existing protocol stack. In the <transmission pattern>, the packet processing inline insertion unit 121 passes the "transmission packet" as output to the NIC driver unit 122 (see symbol q in FIG. 2).

[0084] In the <transmission pattern>, the NIC driver unit 122 of the OS 120 accepts a "transmission packet" from the packet processing inline insertion unit 121 as an input. The NIC driver unit 122 abstracts an interface specific to each NIC type. In the <transmission pattern>, the NIC driver unit 122 passes the "transmission packet" to the NIC 111 as an output (see symbol d in FIG. 2). The NIC 111 transmits the packet to the NIC hardware 300 connected via the NW1.

[0085] The ACC function data parsing unit 310 of the NIC hardware 300 receives a packet from the NIC 111 of the client 100 (see symbol q in FIG. 2). The ACC function data parsing unit 310 deserializes the input packet data, acquires the function name and multiple arguments from the input data, and instructs the data transfer unit 320 to transfer the data to the ACC argument recording unit 201 of the server 200. When the ACC function data parsing unit 310 detects the final packet, it also instructs the data transfer unit 320 to transfer the data to the ACC function execution trigger recording unit 202 of the server 200. The format of the data to be parsed by the ACC function data parsing unit 310 is shown in FIG.

[0086] The data transfer unit 320 receives as input the "transfer destination" and "data to be transferred" from the ACC function data parsing unit 310, and passes the "data to be transferred" to the specified transfer destination as output (see symbol r in FIG. 2).

[0087] The ACC argument recording unit 201 of the user land APL 230 of the server 200 receives as input the "data to be transferred" from the data transfer unit 320 and records it.

[0088] The ACC function execution opportunity recording unit 202 records whether the arguments recorded in the ACC argument recording unit 201 have become complete and the ACC function is in an executable state. The ACC function execution opportunity recording unit 202 receives an executable opportunity from the data transfer unit 320 as input, and the state is updated by the data transfer unit 320.

[0089] The ACC function execution opportunity confirmation unit 203 constantly monitors the ACC function execution opportunity recording unit 202 as input (see symbol s in FIG. 2) and confirms whether the ACC function execution opportunity is in an executable state. The ACC function execution opportunity confirmation unit 203 refers to the ACC function execution opportunity recording unit 202 and detects, based on the data recorded in the ACC argument recording unit 201, that the offload function execution unit 204 has become able to execute the ACC function (see symbol t in FIG. 2).

[0090] The offload function execution unit 204 executes the accelerator function based on the input function name and arguments, and shares the result with the accelerator 205 of the server HW 210 . In the <execution pattern>, the offload function execution unit 204 receives, as input, “function name and arguments” from the ACC argument recording unit 201. In the <execution pattern>, the offload function execution unit 204 passes, as output, “ACC instruction data” to the accelerator 205 (see symbol u in FIG. 2).

[0091] Off-road return trip In the <transmission pattern>, the accelerator 205 passes the "execution result" to the offload function execution unit 204 (see symbol v in FIG. 2). In the <result response pattern>, the offload function execution unit 204 receives, as an input, an “execution result” from the accelerator 205. In the <result response pattern>, the offload function execution unit 204 passes, as an output, a “function name and function execution result” to the ACC function and return value data packetization unit 330 of the NIC hardware 300 (see symbol w in FIG. 2).

[0092] The ACC function and return value data packetization unit 330 receives as input a "function name and arguments" from the offload function execution unit 204. The ACC function and return value data packetization unit 330 converts the input function name and function execution result into data as a UDP / IP packet and its payload. The ACC function and return value data packetization unit 330 also serializes the input function name and function execution result according to a predetermined format to convert them into a single piece of data. The ACC function and return value data packetization unit 330 passes a "transmission packet" as output to the NIC unit 111 of the client 100 (see symbol x in FIG. 2).

[0093] The NIC driver unit 122 of the client 100 receives the packet from the NIC 111, and passes it to the packet processing inline insertion unit 121 (see symbol m in FIG. 2).

[0094] In the <reception pattern>, the packet processing inline insertion unit 121 accepts a "received packet" from the NIC driver unit 122 as an input. The packet processing inline insertion unit 121 exchanges the input packet data with the device driver without going through an existing protocol stack. In the <reception pattern>, the packet processing inline insertion unit 121 passes the "received packet" to the ACC function & response data parsing unit 134 as an output (see symbol n in FIG. 2).

[0095] The ACC function and response data parsing unit 134 deserializes the input packet data to obtain the function name and execution result from the input data, and passes them to the ACC function proxy response unit 135 (see symbol o in FIG. 2).

[0096] The ACC function proxy response unit 135 receives as input the "function name and execution result" from the ACC function and response data parsing unit 134. The ACC function proxy response unit 135 executes the ACC function proxy response by middleware having an IF compatible with the prescribed API. The ACC function proxy response unit 135 passes a "return value" as output to the user application unit 131 (see symbol p in FIG. 2). The user application unit 131 receives the function execution result from the ACC function proxy response unit 135 .

[0097] In the computational processing offload system 1000 of this embodiment, the OS 120 provides dedicated functions (ACC function and argument data packet generation unit 133, ACC function and response data parsing unit 134, ACC function and return value data packetization unit 330, and ACC function data parsing unit 310) for the "L3 / L4 protocol stack" and "ACC function and argument data" for each of the "parsing function" and "packet generation function" as functions within the OS. As a result, the dedicated functions described above operate as functions within the OS, making it possible to reduce overhead caused by data linkage between the APL and the OS (this will be explained in comparison with FIGS. 6 and 7 below).

[0098] Furthermore, the dedicated functions are linked to the NIC driver unit 122 by the packet processing inline insertion unit 121. As a result, since the dedicated functions are linked to the NIC driver unit 122 by the packet processing inline insertion unit 121, it is possible to reduce overhead between the NIC driver unit 122 and the dedicated functions.

[0099] Next, we will explain the overhead caused by data linkage between APL and the OS. [Overhead caused by data exchange between APL and OS] 6 and 7 are diagrams for explaining overhead caused by data linkage between an APL and an OS. <<Middleware processing of existing technology>> Fig. 6 is a diagram for explaining an overview of middleware processing in the receiving section of a client of the existing technology. This middleware processing is taken as an example of middleware processing using a socket-based remote ACC. The socket-based remote ACC middleware can use rCUDA (Remote Compute Unified Device Architecture) or the like.

[0100] <OSカーネル500> As shown in FIG. 6, the OS kernel 500 includes a NIC driver (HIRD handler) 501, which is a handler that is called when a processing request occurs in a NIC 61 (physical NIC), which is a network interface card, and executes the requested processing (hardware interrupt).

[0101] The OS kernel 500 accepts hardware interrupts (HW) (see symbol aa in FIG. 6) or software interrupts (SW) (see symbol bb in FIG. 6). The OS kernel 500 includes a Soft IRQ handler process·packet reception process 502, which is a handler that is called (queued) (see symbol cc in FIG. 6) by the occurrence of a processing request from the NIC driver (HIRD handler) 501 and executes the requested packet reception process (software interrupt), a Soft IRQ handler process·L2,L3 protocol process 503, which is a handler that executes L2,L3 protocol process (software interrupt) after receiving the packet reception process, and a packet reaping process (NAPI) 504 that repeats the Soft IRQ handler process·L2,L3 protocol process 503 and performs packet reaping process (NAPI). Incidentally, reaping a queue refers to deleting the corresponding queue entry from the buffer by referring to the contents of the packet stored in the buffer and taking into consideration the next process to be performed on the packet.

[0102] In the OS kernel 500, there is disposed a Soft IRQ handler processing / L4 protocol processing 505 which is a handler that executes Soft IRQ handler processing / L4 protocol processing (software interrupt) upon receiving a Soft IRQ handler processing / L2, L3 protocol processing 503. In addition, outside the OS kernel 500, there is disposed a Socket Queue 507 which stores a queue generated by a Soft IRQ handler processing / L4 protocol processing 506 (see symbol ee in FIG. 6).

[0103] <rfpga600> The rFPGA 600 is divided into an rFPGA purse and an rFPGA execution unit, and the rFPGA purse receives a software interrupt (SW) (see symbol ff in Figure 6). In the rFPGA 600, a Socket receive buffer 602, an rFPGA parsing (binding) and transfer end detection process 603, an rFPGA execution memory area 604, and a Write Enqueue Buffer 605 are arranged. The Socket receive buffer 602 copies the output of the SocketQueue 507 sent via the SocketAPI 601 (see symbol gg in FIG. 6) and temporarily stores it. The rFPGA parse (connection) and transfer end detection process 603 receives the data stored in the socket receive buffer 602 (see symbol hh in FIG. 6), and performs rFPGA parse connection and transfer end detection. The rFPGA execution memory area 604 copies and saves the results of the rFPGA parsing (binding) and transfer end detection process 603 (see symbol jj in FIG. 6). (Write Enqueue Buffer) 605 executes OpenCL functions based on the rFPGA parsed and combined data from the rFPGA execution memory area 604.

[0104] <Accelerator 62> The accelerator 62 receives the OpenCL function execution result held in the Write Enqueue Buffer 605 (see symbol kk in FIG. 6) and executes the ACC calculation process.

[0105] In the existing technology Socket-based remote ACC utilization middleware processing shown in Figure 6, overhead occurs in the Soft IRQ handler processing L2, L3 protocol processing 503 and Soft IRQ handler processing / L4 protocol processing 505 of the OS kernel 500, and in the Socket receive buffer 602 and rFPGA parsing (binding) and transfer end detection processing 603 of the rFPGA 600 (overhead caused by the process of selecting an L4 / L3 protocol stack with multiple processes, and overhead caused by the NIC driver exchanging data via the existing protocol stack).

[0106] <<Computational Processing Offload System 1000 NIC Hardware 300 Processing>> 7 is a diagram for explaining an overview of the processing of the NIC hardware 300 of the computational processing offload system of this embodiment. In explaining Fig. 7, the same processes as those in Fig. 2, Fig. 5 and Fig. 6 are given the same reference numerals, and explanations of overlapping parts will be omitted.

[0107] <NICハードウェア300> The computation offload system of this embodiment is configured by replacing the server-side NIC with NIC hardware 300 shown in Fig. 5. The NIC hardware 300 shown in Fig. 5 is an rFPGA configured from hardware. In the computation offload system shown in Fig. 7, the OS kernel 500 in Fig. 6 and the rFPGA parse of the rFPGA 600 in Fig. 6 are replaced with the NIC hardware 300 (see Fig. 5) configured with an FPGA-NIC. In the case of Fig. 7, the NIC hardware 300 is configured with a 40G-MAC 350 for L1 processing, and an L2 parse, an L3 parse, an L4 parse, and an rFPGA parse configured with an L2, L3, L4, and rFPGA header analysis circuit 360. The NIC hardware 300 also includes a final packet notification unit 361 and a Streaming DMA 362.

[0108] 7, since the rFPGA purse of the rFPGA 600 is incorporated in the NIC hardware 300, the rFPGA execution unit of the rFPGA 600 is provided with a transfer completion bit 607 that reflects a notification from the NIC hardware 300 (see symbol mm in FIG. 7), and transfer end detection 608 by polling (see symbol nn in FIG. 7) between the Write Enqueue Buffer 605. The copy of the Streaming DMA 362 is directly transferred to the rFPGA execution memory area 604 (see symbol ll in FIG. 7).

[0109] As a result, the computational processing offload system shown in FIG. 7 has reduced latency compared to the Socket-based remote ACC utilization middleware shown in FIG. 6 due to the following three features: (1) Reducing the number of memory copies in the CPU Compared to the Socket-based remote ACC usage middleware shown in Figure 6, this reduces the number of buffer copies required when receiving each packet and the number of copies required for binding when parsing. (2) Reducing the number of interruptions Since DMA transfer is performed directly from the L2, L3, L4, and rFPGA header analysis circuit 360 and the completion is detected by polling, the number of interrupts and overhead can be reduced. (3) Speeding up parsing by implementing circuits Parsing can be performed at high speed by implementing it using hardware (HW) based on, for example, a static random access memory (SRAM).

[0110] [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. 8 and the flowcharts of FIGS.

[0111] FIG. 8 is a control sequence showing the offload processing of the computation offload system 1000 of FIGS. As shown in Figure 8, client 100 (see Figures 1 and 2) executes offload processing during transmission (S100; see Figure 9), and transmits the processing result as data to NIC hardware 300 and server 200 (see Figures 1 and 2) via NW1 (see Figures 1 and 2) (S1; see data transmission sequence).

[0112] The NIC hardware 300 and the server 200 receive the data transmitted from the client 100 via the NW1, and execute the offload process in the server (S200; see FIG. 10).

[0113] The server 200 and the NIC hardware 300 transmit the ACC function processing result to the client 100 via the NW1 (S2; see data transmission sequence).

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

[0115] FIG. 9 is a flowchart showing the offload process (the process of S100 in FIG. 8) during transmission by the client 100 of the computation offload system 1000 in FIGS. In step S101, the user application unit 131 calls an API and outputs a "function name and arguments." In step S 102 , the ACC function proxy reception unit 132 receives the “function name and arguments” from the user application unit 131 , and passes the “function name and arguments” to the ACC function and argument data packet generation unit 133 .

[0116] In step S103, ACC function / argument data packet generator 133 serializes the input "function name and multiple arguments" according to a predetermined format, converts it into single data, and outputs it as a "transmission packet."

[0117] In step S104, the packet processing inline insertion unit 121 exchanges the input packet data ("transmission packet") with the device driver (NIC driver unit 122) without going through an existing protocol stack.

[0118] In step S105, the NIC driver unit 122 accepts the “transmission packet” from the packet processing inline insertion unit 121, abstracts it into an interface specific to each NIC type, and passes it to the NIC 111. In step S106, the NIC 111 transmits the packet to the NIC hardware 300 connected via the NW1.

[0119] FIG. 10 is a flowchart showing the offload process (the process of S200 in FIG. 8) of the NIC hardware 300 and the server 200 of the computation offload system 1000 in FIG. 1 and FIG. In step S 201 , the ACC function data parsing unit 310 of the NIC hardware 300 deserializes packet data input from the client 100 side according to a predetermined protocol format, and instructs the data transfer unit 320 to transfer the data to the ACC argument recording unit 201 .

[0120] In step S202, the ACC function data parsing unit 310 determines whether or not the packet is the last packet, and if it is not the last packet, the process returns to step S201. If it is the last packet, the process proceeds to step S203. As described above, the ACC function data parsing unit 310 checks the control data (see FIG. 3) added to the "control bit" of the packet to confirm that it is the last divided packet.

[0121] In step S203, the data transfer unit 320 of the NIC hardware 300 accepts the "transfer destination" and "data to be transferred" from the ACC function data parsing unit 310, and passes the "data to be transferred" to the specified transfer destination.

[0122] On the other hand, in step S204, the data transfer unit 320 receives an “executable opportunity” from the ACC function data parsing unit 310. 10 are functions executed by the NIC hardware 300. Thereafter, steps S205 to S210 are executed by the server 200, and step S211 (see dashed box qq in FIG. 10) is executed again by the NIC hardware 300.

[0123] In step S205, ACC argument recording unit 201 accepts and records the "data to be transferred" from data transfer unit 320.

[0124] In step S206, the ACC function execution opportunity recording unit 202 records whether the arguments recorded in the ACC argument recording unit 201 have become complete and the ACC function is in an executable state.

[0125] In step S207, the ACC function execution opportunity confirmation unit 203 refers to the ACC function execution opportunity recording unit 202 and detects, based on the data recorded in the ACC argument recording unit 201, that the offload function execution unit 204 has become able to execute the ACC function.

[0126] In step S208, the offload function execution unit 204 executes the accelerator function based on the input function name and arguments, and shares the result with the accelerator 205.

[0127] In step S209, the accelerator 205 performs a specific calculation at high speed based on the input from the CPU.

[0128] In step S 210 , the offload function execution unit 204 accepts the “execution result” from the accelerator 205 , and passes the “function name and function execution result” to the ACC function and return value data packetization unit 330 of the NIC hardware 300 .

[0129] In step S211, the ACC function / return value data packetization unit 330 of the NIC hardware 300 converts the input function name and function execution result into data as a UDP / IP packet and its payload, and also serializes the input function name and function execution result according to a predetermined format to convert them into a single piece of data.

[0130] FIG. 11 is a flowchart showing the offload process (the process of S300 in FIG. 8) 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 hardware 300 connected via the NW1.

[0131] In step S 302 , the NIC driver unit 122 accepts a “received packet” from the NIC 111 , abstracts it into an interface specific to each NIC type, and passes it to the packet processing inline insertion unit 121 .

[0132] In step S303, the packet processing inline insertion unit 121 exchanges the input packet data ("received packet") with the device driver (NIC driver unit 122) without going through the existing protocol stack, and passes the "received packet" to the ACC function / response data parsing unit 134.

[0133] In step S304, the ACC function / response data parsing unit 134 deserializes the input packet data to obtain the function name / execution result from the input data, and passes it to the ACC function proxy response unit 135.

[0134] In step S305, the ACC function proxy response unit 135 accepts the “function name·execution result” from the ACC function·response data parsing unit 134, and passes the “return value” to the user application unit 131.

[0135] In step S 306 , the user application section 131 accepts the function execution result from the ACC function proxy response section 135 .

[0136] [Variations] <Variation 1> In the computation offload system 1000 of FIG. 1 and FIG. 2, the accelerator offload on the server side is configured to go through the CPU, but the accelerator offload processing may be performed inside the NIC hardware 300 (NIC with parsing function: NIC capable of high-performance L2 / L3 / L4 / ACC function argument processing) in the form of <Variant 1>.

[0137] Fig. 12 is a schematic diagram of a computation offload system according to <Modification 1> of an embodiment of the present invention. 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 will be omitted. As shown in FIG. 12, a computation offload system 1000A according to the first modification includes a server 200A and NIC hardware 300A. In the server 200A, the ACC argument recording unit 201, the ACC function execution trigger recording unit 202, the ACC function execution trigger confirmation unit 203, and the offload function execution unit 204 of the userland APL 230 of the server 200 in Fig. 2 are transferred to the NIC hardware 300A. Therefore, the userland APL 230A of the server 200A does not have the above-mentioned functional units.

[0138] The computation offload system 1000A according to the first modification performs accelerator offload processing within the NIC hardware 300A that includes the ACC function data parsing unit 310 and the data transfer unit 320, and returns the result to the server 200A. This allows the accelerator offload to be performed without the intervention of the CPU on the server 200A side, and reduces the processing load on the server 200A. In addition, since the NIC hardware 300A is configured by hardware (HW), it is possible to achieve high speed.

[0139] <Variation 2> In the computation offload system 1000 of FIG. 1 and FIG. 2, an example has been described in which the NIC hardware 300 (a NIC with a parsing function: a NIC capable of highly functional L2 / L3 / L4 / ACC function argument processing) is provided on the server-side NIC. A similarly high-performance NIC (NIC hardware 300) may be installed on both the client side and the server, or only on the client side. In the following, in <Modification 2>, an example in which NIC hardware 300B is installed in a client will be described.

[0140] Fig. 13 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 and Fig. 2 are assigned the same reference numerals, and explanations of overlapping parts will be omitted. As shown in FIG. 13, a computation offload system 1000B according to the second modification includes a client 100B and NIC hardware 300B on the client side. The client 100B includes a client HW 110B, an OS 120B, and a user land APL 130B. 1 and 2, and the OS 120B does not have the packet processing inline insertion unit 121 and the NIC driver unit 122 of Fig. 1 and 2. The user land APL 130B does not have the ACC function / argument data packet generation unit 133 and the ACC function / response data parsing unit 134 of the user land APL 130 of Fig. 1 and 2.

[0141] The NIC hardware 300B has the same configuration as the NIC hardware 300 of the server 200. That is, the NIC hardware 300B, 300 (NIC with parsing function: NIC capable of advanced L2 / L3 / L4 / ACC function argument processing) is installed on both the client side and the server.

[0142] Off-road outward route (client side only) As shown in Fig. 13, the ACC function proxy reception unit 132 of the user land APL 130B of the client 100B receives as input a "function name and arguments" from the user application unit 131 (see symbol rr in Fig. 13). The ACC function proxy reception unit 132 of the client 100B passes as output a "function name and function execution result" to the ACC function and return value data packetization unit 330 of the NIC hardware 300B without the intervention of the OS 120B (see symbol ss in Fig. 13). The ACC function and return value data packetization unit 330 passes as output a "transmission packet" to the NIC hardware 300 on the server 200 side (see symbol tt in Fig. 13).

[0143] Off-road return (client side only) The ACC function data parsing unit 310 of the NIC hardware 300B on the client 100B side receives a packet from the NIC hardware 300 on the server 200 side (see reference symbol uu in FIG. 13). The ACC function data parsing unit 310 of the NIC hardware 300B deserializes the input packet data, obtains the function name and multiple arguments from the input data, and issues instructions to the data transfer unit 320.

[0144] The data transfer unit 320 of the NIC hardware 300B passes the function name and execution result to the ACC function proxy response unit 135 (see reference symbol vv in FIG. 13).

[0145] The ACC function proxy response unit 135 of the user land APL 130B of the client 100B passes a "return value" as an output to the user application unit 131 (see the symbol ww in FIG. 13).

[0146] As a result, the computation offload system 1000B shown in FIG. 13 can achieve, on the client side, (1) a reduction in the number of memory copies in the CPU, (2) a reduction in the number of interrupts, and (3) an increase in speed by implementing parsing processing as a circuit.

[0147] [Hardware configuration] The clients 100, 100B or the servers 200, 200A of the computation offload systems 1000, 1000A, 1000B according to this embodiment are realized by a computer 900 having a configuration as shown in FIG. 14, for example (the client 100 will be described below as a representative). FIG. 14 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the client 100. As shown in FIG. The computer 900 has a CPU 901 , a ROM 902 , a RAM 903 , a HDD 904 , a communication interface (I / F) 906 , an input / output interface (I / F) 905 , and a media interface (I / F) 907 .

[0148] The CPU 901 operates based on a program stored in the ROM 902 or the HDD 904, and controls each unit of the client 100 shown in Fig. 1. The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started up, programs that depend on the hardware of the computer 900, and the like.

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

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

[0151] The media I / F 907 reads a program or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads a program related to a target process from the recording medium 912 onto the RAM 903 via the media I / F 907, and executes the loaded program. The recording medium 912 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.

[0152] For example, when the computer 900 functions as the client 100 configured as one device according to this embodiment, the CPU 901 of the computer 900 executes a program loaded onto the RAM 903 to realize the functions of the client 100. Furthermore, the data in the RAM 903 is stored in the HDD 904. The CPU 901 reads and executes a program relating to a target process from the recording medium 912. Additionally, the CPU 901 may read a program relating to a target process from another device via a communication network (NW 920).

[0153] While the client 100 of the computation offload system 1000 according to this embodiment has been described above, the server 200 can also be realized by a computer 900 having a similar configuration.

[0154] [effect] As described above, the computation offload system 1000 (see FIGS. 1 and 2) includes a client 100 and a server 200 connected via a network and NIC hardware 300 (NIC function unit), in which the client 100 offloads specific processing of an application to an accelerator 205 arranged in the server for computation. The NIC hardware 300 is characterized by having an accelerator function and argument data parsing unit 310 that deserializes packet data input from the client side in accordance with a predetermined protocol format and acquires a function name and multiple arguments, an accelerator function and return value data packetizing unit 330 that serializes the function name and arguments input from the accelerator in accordance with a predetermined protocol format and packetizes them as payload, and a data transfer unit 320 that transfers the data deserialized by the accelerator function and argument data parsing unit to the server.

[0155] In this way, the computation offload system 1000 includes the NIC hardware 300 on the server 200 side. The NIC hardware 300 includes an accelerator function / argument data parsing unit 310 having a single dedicated function, thereby eliminating and dedicating multiple protocol processes (L2, L3 protocol processing, packet harvesting processing (NAPI), L4 protocol processing, ACC function parsing processing, etc.) that were necessary in the prior art. That is, as shown in an example in FIG. 7, the computation offload system 1000 is represented by limiting the L2, L3, L4, and proprietary protocols to specific protocols, respectively, and making them into dedicated circuits, and interconnecting the various circuits when integrated.

[0156] This makes it possible to eliminate the process of selecting an L4 / L3 protocol stack that has multiple processes, and reduces latency by eliminating the overhead in data linkage between the OS's "protocol stack" and the "ACC function / argument data." In the NIC hardware 300, data linkage reduces the number of selections and copies before data transfer to the server 200, thereby reducing overhead and increasing speed. The NIC hardware 300 is implemented in hardware (HW), and therefore can achieve high speeds.

[0157] In the computational processing offload system 1000 (see Figures 1 and 2), the NIC hardware 300 is placed on the server side, and is characterized in that the NIC hardware 300 transfers data deserialized by the ACC function / argument data parsing unit 310 to the server 200.

[0158] This makes it possible to eliminate the process of selecting an L4 / L3 protocol stack with multiple processes on the server 200 side, and to reduce latency by eliminating the overhead in data linkage between the OS's "protocol stack" and the "ACC function / argument data". In the NIC hardware 300, data linkage reduces the number of selections and copies before data transfer to the server 200, thereby reducing overhead and increasing speed.

[0159] In the computational processing offload system 1000B (see FIG. 13), the NIC hardware 300B is placed on the client side, and the NIC hardware 300B is characterized in that it transfers data deserialized by the ACC function / argument data parsing unit 310 to the client 100B.

[0160] This makes it possible to eliminate the process of selecting an L4 / L3 protocol stack with multiple processes on the client 100B side, and reduces latency by eliminating the overhead in data linkage between the OS's "protocol stack" and the "ACC function / argument data." In the NIC hardware 300, data linkage reduces the number of selections and copies before data transfer to client 100B, eliminating overhead and increasing speed.

[0161] In the computation offload system 1000A (see FIG. 13), the NIC hardware 300A (NIC functional unit) is characterized by comprising an ACC argument recording unit 201 which receives and records data to be transferred from the data transfer unit 320 to the server 100, an ACC function execution trigger recording unit 202 which records whether the arguments recorded in the ACC argument recording unit 201 are complete (the ACC arguments are executable) and the ACC function is executable, an ACC function execution trigger confirmation unit 203 which refers to the ACC function execution trigger recording unit 202 and detects that the offload function execution unit 204 is able to execute the ACC function based on the data recorded in the ACC argument recording unit 201, and an offload function execution unit 204 which executes an accelerator function based on the input function name and arguments and shares the result with the accelerator 205.

[0162] In this way, accelerator offload can be performed without the intervention of a CPU on the server 200A side, and the processing load on the server 200A can be reduced. In addition, since the NIC hardware 300A is configured by hardware (HW), it is possible to increase the speed.

[0163] In this embodiment, the packet processing inline insertion unit 121 (see FIG. 1 and FIG. 2) is arranged in the client 100, but the packet processing inline insertion unit 121 may not be arranged. Although there is no synergistic effect with the present invention, there is an advantage that the system configuration can be simplified.

[0164] 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.

[0165] 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]

[0166] 1 Network (NW) 100 clients 110,110B Client HW 111NIC 120,120B OS 121 Packet Processing Inline Insertion Unit 122 NIC driver part 130,130B Userland APL 131 User Application Part 132 ACC Function Delegate Reception 133 L3 / L4 protocol, ACC function, argument data packet generator (ACC function, argument data packet generator) 134 L3 / L4 protocol ACC function response data parsing part (ACC function response data parsing part) 135 ACC Function Proxy Response Part 200,200A Server 210 Server HW 220 OS 230 Userland APL 300 NIC hardware (NIC function part) 310 L3 / L4 protocol ACC function data parsing part (ACC function data parsing part) 320 Data Transfer Unit 330 L3 / L4 protocol, ACC function, return value data packetizer (ACC function, return value data packetizer) 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 NIC (Network Interface Card) functional unit, the client offloading a specific process of an application to an accelerator arranged in the server for computation, The NIC function unit includes: an accelerator function / argument data parsing unit that deserializes packet data input from a client side in accordance with a predetermined protocol format and acquires a function name and multiple arguments; a data transfer unit that transfers the data deserialized by the accelerator function / argument data parsing unit to the server; an accelerator function / return value data packetization unit that serializes the function name / argument input from the accelerator in accordance with a predetermined protocol format and packets the function name / argument as a payload; and an ACC argument recording unit that receives and records data to be transferred from the data transfer unit to the server; an ACC function execution timing recording unit for recording whether the ACC argument and the ACC function recorded in the ACC argument recording unit are in an executable state; an ACC function execution timing confirmation unit that refers to the ACC function execution timing recording unit and detects that the offload function execution unit is able to execute an ACC function based on data recorded in the ACC argument recording unit; An offload function execution unit that executes an accelerator function based on the input function name and arguments and transmits the result to the accelerator. A computation offload system comprising:

2. A computation offload system comprising: a client and a server connected via a network and a NIC (Network Interface Card) functional unit, the client offloading a specific process of an application to an accelerator arranged in the server for computation, The NIC function unit is Deserializing packet data input from a client side in accordance with a predetermined protocol format to obtain a function name and a plurality of arguments; transferring the deserialized data to the server; a step of serializing the function name and arguments input from the accelerator in accordance with a predetermined protocol format and packetizing the function name and arguments as a payload; receiving data to be transferred to the server and recording the data in an ACC argument recording unit; recording in an ACC function execution timing recording unit whether the ACC argument and the ACC function recorded in the ACC argument recording unit are in an executable state; detecting that the ACC function has become executable based on data recorded in the ACC argument recording section by referring to the ACC function execution trigger recording section; Executing an accelerator function based on the input function name and arguments, and linking the result to the accelerator.

13. A computation offloading method comprising:

Images