Calculation processing offload system, calculation processing offload method, and program

Abstract

This server has a function call information reception / parsing unit (231) that extracts function call information for a function name and an argument from data received from a client (100) side, a subsequent function necessity determination unit (235) that determines whether there is a calling function in the received function name and argument, and a subsequent function proxy execution unit (236) that, if it has been determined that there is a calling function, instructs a function execution unit (233) regarding a subsequent function corresponding to the calling function, and causes the same to perform proxy execution thereof. A client (100) has a subsequent function call proxy response unit (136) that, when notification of the result of executing a calling function has been received from the server (200) side, notifies a user application unit (131) of a response for the calling function for which the execution result was received, and with regard to a subsequent function which the user application unit (131), having received the notification of the response for the calling function, had called, acts as a proxy to respond to the server side with a response for said subsequent function.

Description

[Technical Field]

[0001] The present invention relates to a computational processing offload system, a computational processing 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 client machines deployed at user sites to servers at remote sites (such as data centers located near the users) via a network (hereinafter referred to as NW).

[0003] FIG. 14 is a diagram illustrating the device configuration of an offload system via a network. As shown in FIG. 14, the offload system via the NW1 includes a client 10 deployed 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 user application unit 41, a function set 42, and a transfer unit 43 made up of middleware. The function set 42 is an IF specification using an ACC (Accelerator: a calculation accelerator device) made up of OpenCL (Open Computing Language) or the like. A client application performs computations by calling multiple standard functions and APIs, including functions such as enqueue and dequeue functions that have restrictions on the ordering of calls and the completion of previous functions. The client 10 includes a network interface card (NIC) 21 mounted on the client HW 20 .

[0004] The user application unit 41 is a program executed in the user space. The offload system via the NW is built on the premise of using a specified API (Application Programming Interface) such as OpenCL, and performs input and output with these APIs. The user 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 user application unit 41 running on the client 10 is expected to perform image processing and the like, and therefore requires low computation latency.

[0005] The server 50 includes a server HW 60, an OS 70, an APL 80, a function execution unit 81 configured as offload middleware on the APL 80, and a function runtime 82. The server 50 includes a NIC 61 mounted on the server HW 60 .

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

[0007] In the off-road system shown in FIG. 14, it is preferable to satisfy the following requirements 1 to 3. Requirement 1: The interface operated by the client application does not need to be changed (transparency). Requirement 2: When a client application calls multiple functions and receives the results, the time from the first function call to the last function execution result must be short (minimum) (low latency). Requirement 3: When a client application performs offload processing via the network, it consumes minimal network and CPU resources (resource saving).

[0008] 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). [Prior art documents] [Non-patent literature]

[0009] [Non-Patent Document 1] “rCUDA v20.07alpha User's Guide,” The rCUDA Team, July 2020. [online] [Retrieved April 4, 2022], Internet <URL: http: / / www.rcuda.net / pub / rCUDA_guide.pdf> Summary of the Invention [Problem to be solved by the invention]

[0010] In the offloading system described in Non-Patent Document 1, function call information of a client application is transferred via a network, thereby offloading the application without making any changes to the application. At this time, multiple function calls are executed in the order requested by the client application.

[0011] Existing technologies call functions in the exact order requested by the client application, so the degree to which requirements can be met varies depending on the calling pattern. This leads to the following issues: That is, (1) when multiple functions are called synchronously, resources are saved but latency increases. (2) when multiple functions are called asynchronously, latency is low but resources are high. A specific description will be given below with reference to FIGS. 15 and 16.

[0012] <Pattern 1>: When calling multiple functions synchronously FIG. 15 is a diagram showing a control sequence <pattern 1> when a plurality of functions are called synchronously between the client 10 and the server 50 of the offload system shown in FIG. The offload system shown in FIG. 14 is a computation processing offload system in which a client 10 offloads the processing of an application that performs computation processing by calling a plurality of functions with an execution order to a server 50 for computation processing. Functions that have an execution order are the enqueue function (hereinafter simply called enqueue) (call function) whose purpose is to enqueue something that needs to be executed later, and the dequeue function (hereinafter simply called dequeue) (successor function) whose purpose is to dequeue something that is executed later after the execution of the enqueue function.Other functions that have an execution order include the preparation function for preparation and the execution function that is executed after the execution of the preparation function.

[0013] The user application unit 41 of the client 10 calls the enqueue (symbol a in FIG. 15). The transfer unit 43 transfers the enqueue to the function execution unit 81 of the server 50 via the NW (NW1 in FIG. 14) (symbol b in FIG. 15). In the following description, the NIC21 and NIC61 (FIG. 14) for connecting the NWs will not be shown. The function execution unit 81 of the server 50 performs enqueue execution with the function runtime 82 (reference symbol c in FIG. 15). Thereafter, the function runtime 82 performs queue processing (reference symbol d in FIG. 15).

[0014] The server 50 transmits the enqueue execution result to the transfer unit 43 of the client 10 via the NW (reference symbol e in FIG. 15). The transfer unit 43 passes the enqueue execution result received from the server 50 to the user application unit 41 as an enqueue response (reference symbol f in FIG. 15). The user application unit 41 receives the enqueue response and makes a dequeue call (symbol g in FIG. 15). The transfer unit 43 transfers the dequeue to the server 50 via the NW (symbol h in FIG. 15). The function execution unit 81 of the server 50 executes the dequeue with the function runtime 82 (symbol i in FIG. 15). The server 50 transmits the dequeue execution result to the transfer unit 43 of the client 10 via the NW (reference symbol j in FIG. 15). The transfer unit 43 issues a dequeue response to the user application unit 41, passing the dequeue execution result received from the server 50 to the user application unit 41 (reference symbol k in FIG. 15).

[0015] It should be noted that the "dequeue execution" of both the client 10 and the server 50 may be performed not only by polling but also by an interrupt.

[0016] When multiple functions are called synchronously, the minimum latency is two round trips or more in network latency, as shown by symbols b, e, h, and j in Figure 15. This poses a problem in that the low latency of requirement 2 above is not met.

[0017] <Pattern 2>: When calling multiple functions asynchronously Fig. 16 is a diagram showing a control sequence <pattern 2> when multiple functions are called asynchronously between the client 10 and the server 50 of the offload system shown in Fig. 14. The same processes as in Fig. 15 are denoted by the same reference numerals and their explanations will be omitted. The user application unit 41 of the client 10 calls the enqueue (reference symbol a in FIG. 16). After that, the user application unit 41 calls the dequeue without waiting for the result of the enqueue (reference symbols g1 and g2 in FIG. 16). Here, the dequeue is executed asynchronously using busy poll without waiting for the result of the enqueue.

[0018] The transfer unit 43 transfers the multiple dequeues to the function execution unit 81 of the server 50 via the NW (reference numerals h1 and h2 in FIG. 16). The function execution unit 81 of the server 50 executes dequeues with the function runtime 82 (reference numerals i1 and i2 in FIG. 16). Here, it is assumed that the dequeue execution (reference numeral i1 in FIG. 16) is a "failure" and the dequeue execution (reference numeral i2 in FIG. 16) is a "success", and the server 50 transmits each dequeue execution result to the transfer unit 43 of the client 10 via the NW (reference numerals j1 and j2 in FIG. 16). The transfer unit 43 sends a dequeue response to the user application unit 41, passing each dequeue execution result received from the server 50 (reference numerals k1 and k2 in FIG. 16).

[0019] In addition, "dequeue execution" on both the client and server sides can be done not only by polling, but also by using interrupts.

[0020] When multiple functions are called asynchronously, the number of calls to subsequent functions (number of arrows; symbols b, h1, h2, j1, j2, and e in Figure 16) is large, consuming network and CPU resources. This poses the issue of not meeting requirement 3 above, which is to save resources.

[0021] The present invention has been made in view of this background, and aims to achieve both a reduction in the number of function calls via a network and low latency while maintaining the function interface. [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, in which the client offloads to the server the processing of an application that performs computation by calling a plurality of functions having an execution order, the functions having an execution order including a call function that requires subsequent execution and a subsequent function that is executed after the execution of the call function, and the server includes a function execution unit that executes the specified function, and a function call unit that extracts information that can identify the function and function call information of arguments from data received from the client side. The computing offload system comprises a function call information receiving unit that extracts the information, a subsequent function necessity determination unit that determines whether the called function is included in the information and arguments that can identify the function received from the function call information receiving unit, and a subsequent function proxy execution unit that, if the subsequent function necessity determination unit determines that the called function is included, instructs the function execution unit to execute the subsequent function corresponding to the called function on behalf of the function, and the client has a subsequent function call proxy response unit that responds to the subsequent function called by the application on behalf of the server side. [Effects of the Invention]

[0023] According to the present invention, it is possible to reduce the number of function calls via a network and achieve low latency while maintaining the function interface. [Brief explanation 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; [Figure 2] 1 is a diagram illustrating an example of the configuration of a function / argument data packet of a computation offload system according to an embodiment of the present invention. FIG. [Figure 3] FIG. 10 is a diagram showing a control sequence <pattern 1> when multiple functions are called synchronously between a client and a server in the computation offload system according to the embodiment of the present invention. [Figure 4]FIG. 10 is a diagram showing a control sequence <pattern 2> when multiple functions are called asynchronously between a client and a server in the computation offload system according to the embodiment of the present invention. [Figure 5] FIG. 10 is an operational explanatory diagram illustrating "execution of an enqueue function" in the computation offload system according to the embodiment of the present invention. [Figure 6] FIG. 10 is an operational explanatory diagram illustrating an "enqueue function response" of the computation offload system according to the embodiment of the present invention. [Figure 7] FIG. 10 is an operational explanatory diagram illustrating "automatic execution of a dequeue function" in the computation offload system according to the embodiment of the present invention. [Figure 8] FIG. 10 is an operational explanatory diagram illustrating "completion of a dequeue function" in the computation offload system according to the embodiment of the present invention. [Figure 9] 4 is a control sequence illustrating offload processing of the computation offload system according to the embodiment of the present invention. [Figure 10A] 10 is a flowchart illustrating an offload process during transmission by a client in the computation offload system according to the embodiment of the present invention. [Figure 10B] 10 is a flowchart illustrating an offload process during transmission by a client in the computation offload system according to the embodiment of the present invention. [Figure 11A] 10 is a flowchart illustrating an offload process of a server in the computation offload system according to the embodiment of the present invention. [Figure 11B] 10 is a flowchart illustrating an offload process of a server in the computation offload system according to the embodiment of the present invention. [Figure 12] 10 is a flowchart illustrating an offload process at the time of reception by a client of the computational processing offload system according to the 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 client in the computational processing 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. 15 is a diagram showing a control sequence <pattern 1> when multiple functions are called synchronously between the client and server of the offload system shown in FIG. [Figure 16] FIG. 15 is a diagram illustrating a control sequence <pattern 2> when a plurality of functions are called asynchronously between the client and the server of the offload system illustrated in FIG. DETAILED DESCRIPTION OF THE INVENTION

[0025] Hereinafter, a processing 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) 1 is a schematic diagram of a computational processing 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). As shown in FIG. 1, the computational processing offload system 1000 includes a client 100 and a server 200 connected via a network 1, and is an offload system in which the client 100 offloads the processing of an application that performs computational processing by calling multiple functions with an execution order to the server for computational processing.

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

[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 receives "transmission data" from the function call information packetization and transmission unit 134 as input, and passes the "transmission data" to the NW1 as output. In the <reception pattern>, the NIC 111 receives "reception data" from the NW 1 as input, and passes the "reception data" to the reception content determination and storage unit 135 as output.

[0028] APL130 The APL 130 includes a user application unit 131, a function call reception and response unit 132, a subsequent function determination unit 133, a function call information packetization and transmission unit 134, a received content determination and storage unit 135, and a subsequent function call proxy response unit 136. The subsequent function determination unit 133 and the subsequent function call proxy response unit 136 constitute a proxy response function group for subsequent function calls (dotted line box x in FIG. 1).

[0029] <User application part 131> The user application unit 131 is a program executed in user space. It is constructed on the premise of using APIs defined by OpenCL, DPDK BBDevAPI (registered trademark), etc., and performs input and output with these APIs. The user application unit 131 has, as output, a "function name and arguments" for the function call reception and response unit 132. The user application unit 131 receives, as input, a "function execution result" from the function call reception and response unit 132. The user application unit 131 may have another output destination, such as an image drawing destination on a display.

[0030] <Function call reception / response unit 132> The function call reception and response unit 132 is realized as middleware with an interface compatible with a predefined API. It has an interface equivalent to a prescribed API such as OpenCL or DPDK BBdevAPI, and accepts API calls from the user. The function call reception and response unit 132 is prepared as a binary file separate from the user application, and is realized in a "dynamic library format" in which dynamic linking and calling is performed at runtime.

[0031] In the <call pattern>, the function call reception and response unit 132 receives as input the “function name (information that can identify the function) and arguments” from the user application unit 131, and passes the “function name and arguments” to the subsequent function determination unit 133 as output. Here, the "function name" is an example of information that can identify a function. Information that can identify a function is the identification of the type of function (function identifier), and in addition to the "function name," there is, for example, a function ID (number). In the following explanation, the "function name" is used to identify the type of function. In the <response pattern>, the function call acceptance and response unit 132 accepts the “function execution result” from the received content determination and storage unit 135 and responds with the “function execution result” to the user application unit 131 as an output. The function call acceptance / response unit 132 may be in a "static library format" that is linked to the user application when the program is generated and executed as an integrated unit.

[0032] <Subsequent function determination unit 133> The successor function determination unit 133 determines whether the input function name matches a successor function (dequeue), and depending on the determination result, decides whether to execute a function call via the network (function call information packetization and transmission unit 134) or a local function call (successor function call proxy response unit 136). The successor function determination unit 133 holds a "list of functions with successor functions" (not shown) for determining whether the function is a successor function, and determines whether the input function name matches this "list of functions with successor functions" by comparing it with this "list of functions with successor functions." Successor function determination unit 133 receives, as input, the “function name and arguments” from function call reception and response unit 132. Successor function determination unit 133 passes, as output, the “function name and arguments” to function call information packetization and transmission unit 134 or successor function call proxy response unit 136.

[0033] The match determination of the subsequent function may be performed based on the result of an inquiry made to an external server.

[0034] Furthermore, the subsequent function determination unit 133 may be configured to predict the timing of receiving the result from the received content determination and storage unit 135 based on the network latency required for communication between NIC111 and NIC211 (described later), and have a function to wait for a response until that timing, thereby reducing the total number of times the function is executed.

[0035] <Function call information packetization and transmission unit 134> The function call information packetization and transmission unit 134 converts the input function name and arguments into data as an L2 frame and its payload that can be transmitted by the NIC 111 and NIC 211. The function call information packetization and transmission unit 134 serializes the input function name and multiple arguments according to a predetermined format and converts them into a single piece of data.

[0036] FIG. 2 is a diagram showing an example of the structure of the function / argument data packet 150. As shown in FIG. The function and argument data packet 150 is formatted with an L2 frame (0 to 14 bytes), a function ID (up to 34 bytes), argument 1 (up to 50 bytes), and argument 2 (up to 54 bytes).

[0037] The function call information packetizing and transmitting unit 134 receives, as input, the "function name and arguments" from the subsequent function determining unit 133. The function call information packetizing and transmitting unit 134 passes, as output, "transmission data" to the NIC 111.

[0038] The data format may be not only an L2 frame but also data with L3 and L4 headers. The L3 / L4 protocol may be other than TCP / IP (Transmission Control Protocol / Internet Protocol), or a protocol that uses only L3 by eliminating part of L3 / L4. 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. If the argument size is large, a function for dividing the packet into multiple packets may be provided. In this case, the last divided packet is given control data notifying the final packet as shown in FIG.

[0039] <Received content determination and storage unit 135> The received content determination and storage unit 135 deserializes the received packet data and extracts the "function name" and "function execution result." The received content determination and storage unit 135 determines the type of function from the "function name," and if it is not a "successor function," notifies the function call acceptance and response unit 132 of the "function execution result." If it is a "successor function," the received content determination and storage unit 135 saves the result in preparation for a request from the subsequent function call proxy response unit 136 to obtain the "function execution result."

[0040] The received content determination and storage unit 135 receives packet data from the NIC 111 as input. In <output pattern 1>, if the function type is not a "successor function", the received content determination and storage unit 135 responds as an output with a "function execution result" to the function call acceptance and response unit 132. As an input, it accepts a request to acquire the function execution result from the successor function call proxy response unit 136. In <output pattern 2>, the received content determination and storage unit 135 responds to the subsequent function call proxy response unit 136 with the "function execution result" as an input.

[0041] The trigger for the result notification from the received content determination and storage unit 135 to the subsequent function call proxy response unit 136 does not have to be a polling type triggered by a query from the subsequent function call proxy response unit 136, but may be a type in which the notification is actively sent from the received content determination and storage unit 135. For example, the notification may be sent from the received content determination and storage unit 135 using an interrupt function of the CPU.

[0042] <Subsequent Function Call Proxy Response Unit 136> When the subsequent function call proxy response unit 136 receives notification of the execution result of the called function (enqueue) from the server 200 side, it notifies the user application unit 131 of the response of the called function that received the execution result, and also responds to the subsequent function (dequeue) that the user application unit 131 called upon receiving the notification of the response of the called function by proxy to the server side with the response of the subsequent function. When the subsequent function call proxy response unit 136 receives notification of the execution result of the called function (enqueue) from the server 200 side, it notifies the user application unit 131 of the response of the called function that received the execution result, and also responds to the subsequent function (dequeue) that the user application unit 131 called upon receiving the notification of the response of the called function by proxy to the server side with the response of the subsequent function.

[0043] The subsequent function call proxy response unit 136 references the "function execution result" held by the received content determination and storage unit 135 based on the input "function name and arguments" and completes the function within the client and responds with the result. Based on the "function execution result" acquired from the received content determination and storage unit 135, the subsequent function call proxy response unit 136 responds with the function execution result to the caller's function call acceptance and response unit 132.

[0044] When subsequent function call proxy response unit 136 refers to received content determination and storage unit 135 and finds that a "function execution result" exists, it notifies function call acceptance and response unit 132 of the execution result. When a "function execution result" does not exist, subsequent function call proxy response unit 136 responds that there is no data.

[0045] The subsequent function call proxy response unit 136 receives as input the "function name and arguments" from the subsequent function determination unit 133. As output, it responds to the function call acceptance and response unit 132 with the execution result of the function.

[0046] [Server 200] As shown in FIG. 1, the server 200 includes a server HW 210, an OS 220, and an APL 230.

[0047] Server HW210 As shown in FIG. 1, the server HW 210 includes a NIC 211 . The NIC 211 is NIC hardware that realizes a network interface. In the <reception pattern>, the NIC 211 receives "reception data" from the client 100 via the NW1 as input, and passes the "reception data" to the function call information reception and parsing unit 231 as output. In the <transmission pattern>, the NIC 211 receives the "function name" and "function execution result" as input from the function response information transmission unit 234, and passes the "function name" and "function execution result" to the NIC 211 of the client 100 via the NW1.

[0048] APL230 As shown in FIG. 1, APL 230 includes a function call information receiving and parsing unit 231 (function call information receiving unit), a function proxy calling unit 232, a function execution unit 233, a function response information sending unit 234, a subsequent function necessity determining unit 235, a subsequent function proxy execution unit 236, and a subsequent function result sending unit 237.

[0049] The subsequent function necessity determination unit 235 and the subsequent function proxy execution unit 236 constitute a group of functions (dashed line box y in FIG. 1) that determine whether or not a function is to be executed autonomously by the server. In addition, the received content determination and storage unit 135 of the client 100 and the function response information transmission unit 234 of the server 200 constitute a group of functions (dashed line box z in FIG. 1) that notify the client of the result of the autonomous execution by the server.

[0050] <Function call information receiving and parsing unit 231> The function call information receiving and parsing unit 231 extracts function call information, such as a function name and arguments, from the data received from the client side. The function call information receiving and parsing unit 231 checks whether data has arrived at the NIC 211 by polling, and if data has arrived, performs receiving processing and parsing, and calls the function proxy calling unit 232. An example of the data format is similar to that of the function call information packetizing and transmitting unit 134 (see the data format in Figure 2). The function call information receiving and parsing unit 231 receives a "received packet" from the NIC 211 as input, and notifies the function proxy calling unit 232 of the "function name and arguments" as output. The arrival of a packet may be detected by an interrupt rather than by polling. Furthermore, if the function call information packetizing and transmitting unit 134 has a function of dividing into a plurality of packets, the function call information receiving and parsing unit 231 may have a combining function.

[0051] <Function proxy calling unit 232> The function proxy call unit 232 instructs the function execution unit 233 to execute the function based on the “function name and arguments” received from the function call information receiving and parsing unit 231, and notifies the subsequent function necessity determination unit 235 to determine whether to trigger the execution of the subsequent function. The function proxy call unit 232 receives as input the “function name and arguments” from the function call information receiving and parsing unit 231, and passes the “function name and arguments” to the function execution unit 233. At this time, the “function name and arguments” are also passed to the subsequent function necessity determination unit 235.

[0052] <Function execution unit 233> The function execution unit 233 is a functional unit that executes a specified function, and is an existing API runtime (for example, OpenCL runtime or BBDEV API runtime). Function execution unit 233 receives "function information and arguments" from function proxy calling unit 232 as input, and passes "function name" and "function execution result" to function response information sending unit 234 as output. The function execution unit 233 may operate an accelerator such as a field programmable gate array (FPGA) / graphics processing unit (GPU) as hardware.

[0053] <Function response information transmission unit 234> The function response information sending unit 234 serializes the "function name" and "function execution result" received from the subsequent function result sending unit 237 or the function execution unit 233 into the form of a packet and notifies the NIC 211, thereby sending it to the client 100 via NW1. The function response information transmitting unit 234 receives, as input, notifications of the "function name" and "function execution result" from the subsequent function result transmitting unit 237 or the function executing unit 233. The function response information transmitting unit 234 notifies the NIC 211 of the "function name" and "function execution result" as output.

[0054] <Subsequent function necessity determination unit 235> The subsequent function necessity determining unit 235 determines whether or not the function name and argument received from the function call information receiving and parsing unit 231 include a called function (enqueue). Successor function necessity determination unit 235 compares the "function name and arguments" received from function proxy call unit 232 with the "list of functions with successor functions" held by this function, and determines whether there is a successor function corresponding to the relevant function name. The "list of functions with successor functions" held by successor function necessity determination unit 235 is similar to the "list of functions with successor functions" held by successor function determination unit 133. If a successor function exists, successor function necessity determination unit 235 notifies successor function proxy execution unit 236 of the successor function name, and if no successor function exists, no processing is performed.

[0055] The successor function necessity determination unit 235 receives the "function name and arguments" from the function proxy calling unit 232 as input, and notifies the successor function proxy execution unit 236 of the "successor function name and arguments" as output.

[0056] <Subsequent function proxy execution unit 236> If the successor function necessity determination unit 235 determines that there is a called function (enqueue), the successor function proxy execution unit 236 instructs the function execution unit 233 to execute the successor function (dequeue) corresponding to the called function (enqueue) by proxy. Successor function proxy execution unit 236 instructs function execution unit 233 to call the successor function based on the "successor function name and arguments" received from successor function necessity determination unit 235. If the execution of the successor function is successful and a "function execution result" is obtained, successor function proxy execution unit 236 notifies successor function result transmission unit 237 of the "successor function execution result." If the execution of the successor function fails, successor function proxy execution unit 236 repeats the instruction to function execution unit 233.

[0057] Here, success determination after function execution can be done by checking the content of the function execution result in addition to checking the error code of the function execution result. For example, in a dequeue function that extracts processing results from a queue, "the number of processing results is 0 and there is no error code" is not considered to be completion, but the termination condition can be set to "the number of processing results is 0 or more and dequeued".

[0058] The completion of function execution can be detected not only by repeatedly executing the function through polling, but also by an interrupt. In this case, the caller may call the function by converting a polling-type call into an interrupt-type notification, or vice versa.

[0059] The successor function proxy execution unit 236 receives the "successor function name and arguments" from the successor function necessity determination unit 235 as input. The successor function proxy execution unit 236 sends the "successor function name and arguments" to the function execution unit 233 as output 1 and performs a function call. If the execution of the successor function is successful, the successor function proxy execution unit 236 notifies the successor function result transmission unit 237 of the "execution result of the successor function" as output 2.

[0060] <Subsequent function result transmission unit 237> The subsequent function result transmitting unit 237 notifies the function response information transmitting unit 234 of the “execution result of the subsequent function” received from the subsequent function proxy executing unit 236 . The successor function result sending unit 237 receives the "function name" and "execution result of the successor function" from the successor function proxy execution unit 236 as input, and notifies the function response information sending unit 234 of the "function name" and "execution result of the successor function" as output.

[0061] The operation of the computational processing offload system 1000 configured as described above will now be described. [Operational Overview of the Computational Processing Offload System 1000] The control sequence of the computation offload system 1000 will be described with reference to Figures 3 and 4. In describing Figures 3 and 4, the same control sequences as those in Figures 15 and 16 are denoted by the same reference numerals.

[0062] <Pattern 1>: When calling multiple functions synchronously FIG. 3 is a diagram showing a control sequence <pattern 1> when multiple functions are called synchronously between the client 100 and the server 200 of the computation offload system 1000 shown in FIG. The client 100 has a user application unit 131, a function call information packetizing and transmitting unit 134, and a subsequent function call proxy response unit 136. The server 200 has a function call information receiving and parsing unit 231, a function execution unit 233 (corresponding to the function runtime 82 in FIG. 15), and a subsequent function proxy execution unit 236.

[0063] The user application unit 131 of the client 100 calls the enqueue (symbol a in FIG. 3). The function call information packetizing and transmitting unit 134 transfers the enqueue to the server 200 via the NW (NW1 in FIG. 1) (symbol b in FIG. 3). The function call information receiving and parsing unit 231 of the server 200 executes enqueue with the function executing unit 233 (function runtime) (reference symbol c in FIG. 3). Thereafter, the function executing unit 233 executes queue processing (reference symbol d in FIG. 3).

[0064] Point 1: Execution of subsequent functions completed within server 200 In the example of FIG. 3, the function call information receiving and parsing unit 231 executes an enqueue with the function executing unit 233 (reference symbol c in FIG. 3). In the present invention, when the successor function necessity determining unit 235 (FIG. 1) determines that there is an enqueue (called function), the successor function proxy executing unit 236 instructs the function executing unit 233 to dequeue (successor function) corresponding to the enqueue and executes it as a proxy. The successor function proxy executing unit 236 executes a dequeue process with the function executing unit 233 (reference symbols mm1, mm2, mm3 in FIG. 3). That is, when the successor function proxy executing unit 236 of the server 200 detects an enqueue, it instructs the function executing unit 233 to dequeue corresponding to the enqueue and executes it as a proxy within the server 200 using busy poll. In addition to busy poll, detection using an interrupt format is also possible. Since dequeuing is performed entirely within the server, it is possible to reduce function calls via the network, minimize the number of function calls via the network, and achieve low latency.

[0065] The server 200 transmits the enqueue execution result to the function call information packetizing and transmitting unit 134 of the client 100 via the NW (see symbol e in FIG. 3). The function call information packetizing and transmitting unit 134 of the client 100 passes the enqueue execution result received from the server 200 to the user application unit 131 as an enqueue response (symbol f in FIG. 3).

[0066] Point 2: Subsequent function proxy response within client 100 In the present invention, when the subsequent function call proxy response unit 136 (FIG. 1) receives notification of an enqueue response, it responds to the dequeue called by the user application unit 131 by proxy to the server 200 side with a response to the dequeue. That is, the subsequent function call proxy response unit 136 of the client 100 responds to the dequeue call from the user application unit 131 by proxy within the client 100 until the result is notified from the server 200. In the example of FIG. 3, the subsequent function call proxy response unit 136 receives the dequeue call (code oo1 in FIG. 3) from the user application unit 131, and responds to this dequeue call by proxy within the client 100 with a dequeue response: failure (code oo2 in FIG. 3).

[0067] Since a proxy response is made within the client to the dequeue call until the result notification from the server (the response is completed within the client until the execution result is received from the server), the number of function calls via the network can be reduced. The transparency of the above requirement 1 can be achieved without the need to make any changes to the user application unit 131.

[0068] As mentioned in point 1 above, when the subsequent function proxy execution unit 236 of the server 200 detects an enqueue, it executes a dequeue using busy poll with the function runtime 82 (reference symbols mm1, mm2, and mm3 in FIG. 3). This dequeue execution is a dequeue process that is completed within the server 200. The function call information receiving and parsing unit 231 of the server 200 transmits the dequeue execution result to the subsequent function call proxy response unit 136 of the client 100 (reference number n in FIG. 3). The subsequent function call proxy response unit 136 receives the dequeue execution result notification from the server 200 (reference numeral n in FIG. 3), and returns a dequeue response: success (reference numeral oo3 in FIG. 3) to the user application unit 131.

[0069] In this way, in the server 200, when the successor function necessity determination unit 235 detects an enqueue, the successor function proxy execution unit 236 executes the dequeue process within the server 200 (reference numerals mm1, mm2, and mm3 in FIG. 3). Meanwhile, in the client 100, the successor function call proxy response unit 136 responds by proxy within the client 100 to the dequeue call from the user application unit 131 (reference numeral oo2 in FIG. 3), and upon receiving a dequeue execution result notification from the server 200 (reference numeral n in FIG. 3), ends the proxy response and responds with a dequeue response: success (reference numeral oo3 in FIG. 3) to the user application unit 131.

[0070] The server 200 executes the dequeue process entirely within the server 200. This reduces the number of function calls via the network, and also reduces the number of function calls via the network, thereby achieving low latency. In the example of Fig. 3, the number of network communications can be reduced from four (Fig. 15) to three, thereby achieving low latency and resource savings.

[0071] Until the client 100 receives the dequeue execution result from the server 200, it responds to the dequeue call from the user application unit 131 internally as a proxy and completes the process. This has the advantage that the function interface is maintained, there is no need to make any changes to the client application, and there is no need to change the interface operated by the client application.

[0072] <Pattern 2>: When calling multiple functions asynchronously FIG. 4 is a diagram showing a control sequence <pattern 2> when a plurality of functions are called asynchronously between the client 100 and the server 200 of the computation offload system 1000 shown in FIG. The user application unit 131 of the client 100 performs enqueue (symbol a in FIG. 4). The subsequent function call proxy response unit 136 of the client 100 responds to the dequeue call from the user application unit 131 on its behalf within the client 100 until the result notification is received from the server 200. In the example of Fig. 4, the subsequent function call proxy response unit 136 responds to the dequeue call (reference numeral pp1 in Fig. 4) from the user application unit 131 on its behalf (reference numeral pp2 in Fig. 4), and responds to the dequeue call (reference numeral pp3 in Fig. 4) on its behalf (reference numeral pp4 in Fig. 4). Similarly, it responds to the dequeue call (reference numeral qq1 in Fig. 4) from the user application unit 131 on its behalf (reference numeral qq2 in Fig. 4), and responds to the dequeue call (reference numeral rr1 in Fig. 4) on its behalf (reference numeral rr2 in Fig. 4).

[0073] The subsequent function call proxy response unit 136 has received the result notification from the server 200 before the dequeue call (symbol rr1 in FIG. 4), so the proxy response is successful (symbol rr2 in FIG. 4). Incidentally, the proxy response to the dequeue call (symbol qq1 in FIG. 4) before receiving the result notification from the server 200 is unsuccessful (symbol qq2 in FIG. 4).

[0074] Meanwhile, the function call information receiving and parsing unit 231 of the server 200 executes enqueue processing with the function runtime 82 (reference symbol c in FIG. 4) and also executes dequeue processing (reference symbols mm1, mm2, mm3 in FIG. 4).

[0075] The server 200 transmits the enqueue execution result to the function call information packetizing and transmitting unit 134 of the client 100 (see symbol e in FIG. 4). The function call information packetizing and transmitting unit 134 of the client 100 passes the enqueue execution result received from the server 200 to the user application unit 131 as an enqueue response (symbol f in FIG. 4).

[0076] The function call information receiving and parsing unit 231 of the server 200 transmits the dequeue execution result to the subsequent function call proxy response unit 136 of the client 100 (reference number n in FIG. 4).

[0077] The subsequent function call proxy response unit 136 receives the dequeue execution result notification from the server 200 (reference symbol n in FIG. 4), and returns a dequeue response: success (reference symbol rr2 in FIG. 4) to the user application unit 131.

[0078] In this way, the asynchronous call pattern reduces the number of function calls via the network, thereby saving resources. In the example of Figure 4, the number of network communications can be reduced from six (Figure 16) to three, thereby saving resources.

[0079] [Operation of the computational processing offload system] The operational steps of the computational processing offload system will be described with reference to Figures 5 to 8. The same components as in Figure 1 are given the same reference numerals. Furthermore, functional units in an active state are indicated by bold frames.

[0080] <Step 1>: "Execute the enqueue function" FIG. 5 is an explanatory diagram of the operation of the computation offload system to explain "execution of an enqueue function." The client 100 executes the enqueue function (aa in Figure 5), and the data arrives via the NW1 (bb in Figure 5) at the proxy execution unit (function call information receiving and parsing unit 231, function proxy call unit 232, subsequent function necessity determination unit 235) on the server 200 side (cc in Figure 5).

[0081] Specifically, the enqueue function execution is performed as follows: The function call acceptance / response unit 132 of the client 100 accepts the "function name and arguments" from the user application unit 131 and passes the "function name and arguments" to the successor function determination unit 133. The successor function determination unit 133 accepts the "function name and arguments" from the function call acceptance / response unit 132 and passes the "function name and arguments" to the function call information packetization / transmission unit 134. The successor function determination unit 133 accepts the "function name and arguments" from the function call acceptance / response unit 132. The function call information packetization / transmission unit 134 serializes the input function name and multiple arguments according to a predetermined format and converts them into a single piece of data. In the <reception pattern>, the NIC 111 accepts the "reception data" as input from the function call information packetization / transmission unit 134 and sends it to the server 200 via the NW1. On the server 200 side, the subsequent function necessity determining unit 235 determines that the subsequent function is "necessary."

[0082] <Step 2>: "Enqueue function response" FIG. 6 is an explanatory diagram of the operation of the computation offload system for explaining the "enqueue function response." The server 200 returns the result of the enqueue function to the client 100 via the NW1 (symbol dd in FIG. 6).

[0083] Specifically, the result response of the enqueue function is as follows: Function execution unit 233 accepts "function information and arguments" from function proxy call unit 232, and passes "function name" and "function execution result" to function response information transmission unit 234. Function response information transmission unit 234 serializes the "function name" and "function execution result" received from function execution unit 233 into the form of a packet, and notifies NIC 211 to transmit it to client 100 via NW1.

[0084] The client 100 receives the result and responds to the client application. Specifically, the received content determination and storage unit 135 receives packet data from the NIC 111. Here, the received content determination and storage unit 135 determines that the function type is not a "successor function" and responds with a "function execution result" to the function call acceptance and response unit 132 (see symbol ee in FIG. 6). The function call acceptance and response unit 132 accepts the "function execution result" from the received content determination and storage unit 135 and responds with the "function execution result" to the user application unit 131.

[0085] <Step 3>: "Automatic execution of dequeue function" FIG. 7 is an explanatory diagram of the operation of the "automatic execution of the dequeue function" of the computation offload system. In the client 100 , a subsequent function call proxy response unit 136 makes a proxy response to the execution of the subsequent function (dequeue function) until the received content determination and storage unit 135 receives a result from the server 200 .

[0086] Specifically, the execution of the subsequent function (dequeue function) is as follows: If the function type is a "successor function," the received content determination and storage unit 135 responds with a "function execution result" to the subsequent function call proxy response unit 136. The subsequent function call proxy response unit 136 references the "function execution result" held by the received content determination and storage unit 135 based on the input "function name and arguments," and responds with the result of the function completed within the client. The subsequent function call proxy response unit 136 responds with the function execution result to the caller's function call acceptance and response unit 132 based on the "function execution result" acquired from the received content determination and storage unit 135 (symbol ff in Figure 7). It passes the "function name and arguments." The function call acceptance and response unit 132 accepts the "function execution result" from the received content determination and storage unit 135 (symbol gg in Figure 7), and responds with the "function execution result" to the user application unit 131. The successor function determination unit 133 determines whether the input function name matches a successor function, and depending on the determination result, determines whether to execute a function call via the network (function call information packetization and transmission unit 134) or a local function call (successor function call proxy response unit 136). In this case, the successor function determination unit 133 is in the case of a successor function, and passes the "function name and arguments" to the successor function call proxy response unit 136 (symbol hh in FIG. 7).

[0087] In the server 200, the successor function proxy execution unit 236 continues to execute the dequeue function on behalf of the function execution unit 233 (see symbol ii in FIG. 7). The successor function proxy execution unit 236 sends the "successor function name and arguments" to the function execution unit 233 and performs a function call. The function execution unit 233 executes the specified function. Here, the successor function proxy execution unit 236 continues to execute the dequeue function on behalf of the function execution unit 233.

[0088] Step 4: Completing the dequeue function FIG. 8 is an explanatory diagram of the operation of the computation offload system for explaining "completion of the dequeue function." When the subsequent function proxy execution unit 236 has successfully completed the dequeue process, the server 200 transmits the calculation result to the client 100 .

[0089] The success of the dequeue process is specifically the following operation. If the execution of the successor function is successful, the successor function proxy execution unit 236 notifies the successor function result transmission unit 237 of the "execution result of the successor function." The successor function result transmission unit 237 notifies the function response information transmission unit 234 of the "execution result of the successor function" received from the successor function proxy execution unit 236 (item jj in FIG. 8). The function response information transmission unit 234 receives notification of the "function name" and "function execution result" from the successor function result transmission unit 237. The function response information transmission unit 234 notifies the client 100 of the "function name" and "function execution result" via the NIC 211 (item kk in FIG. 8).

[0090] The client 100 stores the calculation result received from the server 200 in the received content determination and storage unit 135. The received content determination and storage unit 135 responds with this result in response to an inquiry from the subsequent function call proxy response unit 136 (reference numeral 11 in FIG. 8). The subsequent function call proxy response unit 136 responds with the result to the user application unit 131 via the function call acceptance and response unit 132.

[0091] [Offload processing of the computation processing offload system 1000] Next, the offload processing of the computation offload system 1000 will be described with reference to the control sequence of FIG. 9 and the flowcharts of FIGS. 10A to 12. FIG.

[0092] FIG. 9 is a control sequence showing the offload processing of the computation offload system 1000 of FIG. As shown in FIG. 9, client 100 (FIG. 1) performs offload processing during transmission (S10; see FIGS. 10A and 10B) and transmits the processing result to server 200 (FIG. 1) via NW1 (FIG. 1) as data (S1; see data transmission sequence).

[0093] The server 200 receives the data transmitted from the client 100 via the NW1, and executes the offload process in the server 200 (S20; FIGS. 11A and 11B).

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

[0095] The client 100 executes offload processing at the time of reception (S30; FIG. 12).

[0096] 10A and 10B are flowcharts showing the offload process (the process of S10 in FIG. 9) during transmission by the client 100 of the computation offload system 1000 in FIG. In step S201, the user application unit 131 has, as an output, a "function name and arguments" for the function call acceptance and response unit 132, and makes an API call. In step S202, the function call acceptance / response unit 132 accepts the “function name and arguments” from the user application unit 131 and passes the “function name and arguments” to the subsequent function determination unit 133.

[0097] In step S203, subsequent function determination unit 133 accepts the “function name and arguments” from function call acceptance and response unit 132 and passes the “function name and arguments” to function call information packetization and transmission unit 134 or subsequent function call proxy response unit 136.

[0098] In step S204, the successor function determination unit 133 determines whether the input function name corresponds to a successor function. The successor function determination unit 133 checks the input function name against the "list of functions with successor functions" to determine whether the input function name matches a successor function.

[0099] If it corresponds to a successor function (S204: Yes), in step S205, the successor function call proxy response unit 136 responds to the user application unit 131 that the execution result of the successor function is incomplete until it receives a notification of the execution result of the successor function. The successor function call proxy response unit 136 responds to the successor function call by proxy within the client until it receives a result notification from the server 200 (the response is completed within the client until it receives the execution result from the server).

[0100] In step S206, the function call acceptance and response unit 132 accepts the "function execution result" from the received content determination and storage unit 135, and responds with the "function execution result" to the user application unit 131.

[0101] In step S207, the user application unit 131 calls the API and returns to step S202. If the function does not correspond to a successor function in step S204 (S204: No), the process proceeds to step S208 in FIG. 10B.

[0102] In step S208, the function call information packetization and transmission unit 134 serializes the input function name and multiple arguments according to a predetermined format to convert them into a single piece of data. The function call information packetization and transmission unit 134 accepts the “function name and arguments” from the subsequent function determination unit 133 and passes the “transmission data” to the NIC 111.

[0103] In step S209, the NIC 111 accepts the "received data" from the function call information packetizing and transmitting unit 134, transmits the packet to the server 200 connected via the NW1, and ends the processing of this flow.

[0104] 11A and 11B are flowcharts showing the offloading process (the process of S20 in FIG. 9) of the server 200 of the computation offloading system 1000 in FIG. In step S 301 , the NIC 211 accepts “received data” from the client and passes the “received data” to the function call information receiving and parsing unit 231 .

[0105] In step S302, the function call information receiving and parsing unit 231 polls the NIC 211 to check whether data has arrived, and if data has arrived, performs reception processing and parses it. The function call information receiving and parsing unit 231 accepts "received data" from the NIC 211 and notifies the function proxy calling unit 232 of the "function name and arguments."

[0106] In step S303, based on the "function name and arguments" received from the function call information receiving and parsing unit 231, the function execution unit 233 is instructed to execute the function, and a notification is sent to the subsequent function necessity determination unit 235 to determine whether to trigger the execution of the subsequent function.

[0107] In step S304, function execution unit 233 accepts the “function information and arguments” from function proxy calling unit 232, and passes the “function name” and “function execution result” to function response information sending unit 234.

[0108] In step S305, the function response information sending unit 234 serializes the "function name" and "function execution result" received from the subsequent function result sending unit 237 or the function execution unit 233 into the form of a packet and notifies the NIC 211 to send it to the client 100 via NW1.

[0109] In step S306, successor function necessity determination unit 235 compares the "function name and arguments" received from function proxy call unit 232 with the "list of functions with successor functions" of this function, and determines whether there is a successor function corresponding to the function name. If there is a successor function, successor function necessity determination unit 235 notifies successor function proxy execution unit 236 of the successor function name.

[0110] If the successor function necessity determination unit 235 determines in step S307 that there is no successor function corresponding to the function name (S307: No), the function execution unit 233 executes the specified function in step S308, and the process proceeds to step S314.

[0111] If there is a successor function corresponding to the function name in question (S307: Yes), in step S309 successor function proxy execution unit 236 instructs function execution unit 233 to call the successor function based on the "successor function name and arguments" received from successor function necessity determination unit 235. If the execution of the successor function is successful and a "function execution result" is obtained, successor function proxy execution unit 236 notifies successor function result transmission unit 237 of the "successor function execution result." If the execution of the successor function fails, successor function proxy execution unit 236 repeats the instruction to function execution unit 233 (loop processing of S309 to S311 below).

[0112] In step S310, the function execution unit 233 executes the specified function. In step S311, the successor function proxy executing unit 236 determines whether or not the result acquisition has been completed, and if the result acquisition has not been completed (S311: No), the process returns to step S309.

[0113] If result acquisition is completed (S311: Yes), in step S312, the subsequent function result sending unit 237 receives the “function name” and “subsequent function execution result” from the subsequent function proxy execution unit 236, and notifies the function response information sending unit 234 of the “function name” and “subsequent function execution result.”

[0114] In step S313, the function response information transmitting unit 234 serializes the “function name” and “function execution result” received from the subsequent function result transmitting unit 237 or the function executing unit 233 into a packet and notifies the NIC 211 of the packet.

[0115] In step S314, the NIC 211 receives the "function name" and "function execution result" from the function response information transmitting unit 234, and passes the "function name" and "function execution result" to the NIC 211 of the client 100 via NW1, thereby completing the processing of this flow.

[0116] FIG. 12 is a flowchart showing the offload process (the process of S30 in FIG. 9) at the time of reception by the client 100 of the computation processing offload system 1000 in FIG. In step S401, the NIC 111 of the client 100 accepts "received data" from the server 200 connected via the NW1, and passes the "received data" to the received content determination and storage unit 135.

[0117] In step S402, the received content determination and storage unit 135 deserializes the received packet data and extracts the "function name" and "function execution result." The received content determination and storage unit 135 determines the type of function from the "function name," and if it is not a "successor function," notifies the function call acceptance and response unit 132 of the "function execution result."

[0118] In step S403, the successor function determination unit 133 determines whether or not the function is a successor function. If the function is not a successor function (S403: No), the process of this flow ends.

[0119] If it corresponds to a subsequent function (S403: Yes), in step S404, the function call acceptance and response unit 132 accepts the “function execution result” from the received content determination and storage unit 135 and responds with the “function execution result” to the user application unit 131 as an output.

[0120] In step S405, the user application unit 131 receives the "function execution result" as input from the function call reception / response unit 132, and ends the processing of this flow.

[0121] [Hardware configuration] The client 100 or the server 200 of the computation offload system 1000 according to this 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 client 100. As shown in FIG. The computer 900 includes 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 .

[0122] 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 starts up, programs that depend on the hardware of the computer 900, and the like.

[0123] The CPU 901 controls an input device 910 such as a mouse or 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.

[0124] The HDD 904 stores programs executed by the CPU 901 and data used by the programs. 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.

[0125] 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 disc), a magnetic recording medium, a conductive memory tape medium, a semiconductor memory, or the like.

[0126] 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 HDD 904 stores data in the RAM 903. The CPU 901 reads and executes a program related to a target process from the recording medium 912. Alternatively, the CPU 901 may read a program related to a target process from another device via a communication network (NW 920).

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

[0128] [effect] As described above, the computation offload system 1000 includes the client 100 and the server 200 connected via the NW1, and the client 100 offloads to the server 200 the processing of an application (user application unit 131 in FIG. 1 ) that performs computation by calling a plurality of functions that have an execution order, and the computation offload system 1000 performs computation. The functions that have an execution order include a call function (e.g., enqueue) that needs to be executed subsequently, and a subsequent function (e.g., dequeue) that is executed subsequently after the execution of the call function. The server 200 includes a function execution unit 233 that executes the specified function, and a function execution unit 234 that executes the specified function and a function execution unit 235 that executes the specified function and a function execution unit 236 that executes the specified function and a function execution unit 237 that executes the specified function and a function execution unit 238 that executes the specified function and a function execution unit 239 ... a successor function necessity determination unit 235 (FIG. 1) that determines whether or not a called function exists in the information (function name) and arguments that can identify the function received from the function call information reception and parsing unit 231; and a successor function proxy execution unit 236 (FIG. 1) that, when the successor function necessity determination unit 235 determines that a called function exists, instructs the function execution unit 233 to execute the successor function corresponding to the called function by proxy, and the client 100 has a successor function call proxy response unit 136 (FIG. 1) that responds to the successor function called by the user application unit 131 on behalf of the server.

[0129] In this way, the computation offload system 1000 executes subsequent function (e.g., dequeue) processing entirely within the server 200 and the client 100. This reduces the number of function calls via the NW1, thereby achieving low latency. While maintaining the function interface, it is possible to achieve both a reduction in the number of function calls via the NW1 and low latency.

[0130] Furthermore, in the computational processing offload system 1000 (FIG. 1), the server 200 is characterized by having a function execution unit 233 that executes a specified function, a function call information receiving unit (function call information receiving and parsing unit 231 in FIG. 1) that extracts function call information of the function name and arguments from data received from the client 100 side, a successor function necessity determination unit 235 (FIG. 1) that determines whether or not a called function exists in the function name and arguments received from the function call information receiving and parsing unit 231, and a successor function proxy execution unit 236 (FIG. 1) that, when the successor function necessity determination unit 235 determines that a called function exists, instructs the function execution unit 233 to execute the successor function corresponding to the called function by proxy.

[0131] In this way, the computational offload system 1000 completes the dequeue process within the server 200. This reduces the number of function calls via the NW1, minimizing the number of function calls via the NW1 and achieving low latency. In the example of Fig. 3, the number of NW communications can be reduced from four (Fig. 15) to three, achieving low latency and resource savings.

[0132] Furthermore, in the computational processing offload system 1000 (FIG. 1), when the client 100 receives a notification of the execution result of a called function from the server 200 side, the client 100 notifies the user application unit 131 of the response of the called function that has received the execution result, and is characterized by having a subsequent function call proxy response unit 136 (FIG. 1) that responds to the subsequent function called by the user application unit 131 on behalf of the server side with the response of the subsequent function upon receiving the notification of the response of the called function.

[0133] In this way, the client 100 of the computational offload system 1000 responds to dequeue calls internally on behalf of the server 200 until it receives a notification of the execution result of the called function from the server 200 (the response is completed internally until it receives the execution result from the server). This reduces the number of function calls via the network 1. Another advantage is that the function interface is maintained, and there is no need to make changes to the client application, so the interface operated by the client application does not need to be changed.

[0134] In the computational processing offload system 1000, when the subsequent function call proxy response unit 136 (Figure 1) of the client 100 receives a notification of the execution result of the called function from the server 200 side, it notifies the user application unit 131 of the response of the called function that received the execution result, and also responds to the subsequent function that the user application unit 131 called upon receiving the notification of the response of the called function by proxy sending the response of the subsequent function to the server side.

[0135] In this way, the client 100 of the computation offload system 1000 responds to the dequeue call by proxy within the client (the response is completed within the client until the execution result is received from the server), thereby reducing the number of function calls via the NW1.

[0136] In the computation offload system 1000, the subsequent function call proxy response unit 136 (FIG. 1) responds with the execution result of the subsequent function to the application (user application unit 131 in FIG. 1) until it receives a notification of the execution result of the subsequent function from the server 200. The subsequent function call proxy response unit 136 responds with the execution result of the subsequent function, for example, by responding that the execution result of the subsequent function is incomplete, and when it receives a notification of the execution result of the subsequent function, it responds to the user application unit 131 that the execution result of the subsequent function was successful. The response of the execution result of the subsequent function not only notifies whether the function execution was successful, but also notifies the processing result.

[0137] As a result, the client 100 responds to the dequeue call internally as a proxy. Until the server 200 receives a notification of the execution result of the subsequent function, the subsequent function call proxy response unit 136 can complete the dequeue response by, for example, responding to the user application unit 131 that the dequeue execution result is incomplete, and then responding that the execution result was successful when the server 200 receives a notification of the execution result of the dequeue.

[0138] Here, in the computational processing offload system 1000, by having the above-mentioned server 200 and the above-mentioned client 100, when offloading multiple functions with an execution order, such as enqueue processing and dequeue processing, via NW1, it is possible to minimize the number of function calls via NW1 and achieve low latency while maintaining the function interface.

[0139] In the computational processing offload system 1000 (Figure 1), functions with an execution order are characterized by being an enqueue function whose purpose is to enqueue something that needs to be executed subsequently, and a dequeue function whose purpose is to dequeue something that will be executed subsequently after the execution of the enqueue function.

[0140] This allows it to be applied to client applications that have "restrictions on the order of calls and the completion of the previous function," such as enqueue and dequeue functions, with the advantage that the function interface is maintained and no changes are required to the client application. Note that the functions with execution order may be a preparation function for preparation and an execution function that is executed after the preparation function is executed, and the same effect can be obtained.

[0141] 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 using 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 as desired unless otherwise specified. Furthermore, the components of each device shown in the figure are conceptual functional components and do 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 depending on various loads, usage conditions, etc.

[0142] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented by software that causes a processor to interpret and execute programs that implement the respective functions. Information on the programs, tables, files, etc. that implement the respective functions may be stored in a memory, a recording device such as a hard disk or a solid-state drive (SSD), or a recording medium such as an integrated circuit (IC) card, a secure digital (SD) card, or an optical disc. [Explanation of symbols]

[0143] 1 Network (NW) 100 clients 110 Client HW 111 NIC 130 APL 131 User Application Section 132 Function call reception and response section 133 Subsequent function determination section 134 Function call information packetization and transmission unit 135 Received Content Judgment and Storage Unit 136 Subsequent Function Call Proxy Response Unit 200 servers 210 Server HW 211NIC 230 APL 231 Function call information receiving and parsing unit (function call information receiving unit) 232 Function proxy call unit 233 Function execution unit 234 Function response information transmission unit 235 Subsequent function necessity determination section 236 Subsequent Function Proxy Execution Unit 237 Subsequent function result sending part 1000 Computational Processing Offload System

Claims

1. A computation offload system comprising a client and a server connected via a network, wherein the client offloads processing of an application that performs computation by calling a plurality of functions having an execution order to the server for computation, The functions having an execution order include a call function that needs to be executed subsequently and a subsequent function that is executed subsequently after the execution of the call function, The server a function execution unit that executes a specified function; a function call information receiving unit that extracts information that can identify a function and function call information of arguments from data received from a client side; a subsequent function necessity determination unit that determines whether the called function is included in the information and arguments that can identify the function received from the function call information receiving unit; a successor function proxy execution unit that, when the successor function necessity determination unit determines that the called function exists, instructs the function execution unit to execute the successor function corresponding to the called function by proxy, The client: a subsequent function call proxy response unit that responds to the subsequent function called by the application on behalf of the server side by sending a response from the subsequent function; A computational processing offload system comprising:

2. A computation offload system comprising a client and a server connected via a network, wherein the client offloads processing of an application that performs computation by calling a plurality of functions having an execution order to the server for computation, The functions having an execution order include a call function that needs to be executed subsequently and a subsequent function that is executed subsequently after the execution of the call function, The server a function execution unit that executes a specified function; a function call information receiving unit that extracts information that can identify a function and function call information of arguments from data received from a client side; a subsequent function necessity determination unit that determines whether the called function is included in the information and arguments that can identify the function received from the function call information receiving unit; a successor function proxy execution unit that, when the successor function necessity determination unit determines that the called function exists, instructs the function execution unit to execute the successor function corresponding to the called function by proxy. A computational processing offload system comprising:

3. A computation offload system comprising a client and a server connected via a network, wherein the client offloads processing of an application that performs computation by calling a plurality of functions having an execution order to the server for computation, The functions having an execution order include a call function that needs to be executed subsequently and a subsequent function that is executed subsequently after the execution of the call function, The client: When receiving a notification of the execution result of the called function from the server side, notify the application of a response from the called function that has received the execution result; a subsequent function call proxy response unit that responds to the subsequent function called by the application in response to a notification of the response of the called function on behalf of the server side, A computational processing offload system comprising:

4. When the subsequent function call proxy response unit receives a notification of the execution result of the called function from the server side, it notifies the application of a response from the called function that has received the execution result, and responds to the subsequent function that has been called by the application upon receiving the notification of the response from the called function by proxy on the server side with the response from the subsequent function.

2. The computational processing offload system according to claim 1.

5. The subsequent function call proxy response unit The execution result of the subsequent function is not returned to the application until the notification of the execution result of the subsequent function is received from the server side.

2. The computational processing offload system according to claim 1.

6. The functions with execution order are an enqueue function for enqueuing data that needs to be executed subsequently, and a dequeue function for dequeuing data that needs to be executed subsequently after the execution of the enqueue function.

2. The computational processing offload system according to claim 1.

7. A computation offloading method for a computation offloading system, comprising a client and a server connected via a network, in which the client offloads processing of an application that performs computation by calling a plurality of functions with an execution order to the server for computation, the method comprising: The functions having an execution order include a call function that needs to be executed subsequently and a subsequent function that is executed subsequently after the execution of the call function, The server: a function execution step that executes a specified function; a function call information receiving step of extracting information capable of identifying a function and function call information of arguments from data received from the client side; a subsequent function necessity determination step of determining whether the called function is included in the information and arguments capable of identifying the function extracted by the function call information receiving step; a subsequent function proxy execution step of, when it is determined in the subsequent function necessity determination step that there is a called function, executing the subsequent function corresponding to the called function by proxy in the function execution step; The client: a step of responding to the subsequent function called by the application on behalf of the server side with a response from the subsequent function; A computational processing offloading method comprising:

8. A program for causing a computer to function as the server according to claim 2.

9. A program for causing a computer to function as the client according to claim 3.

Images