A method, system and storage medium for improving RPC access efficiency

Abstract

The present invention discloses a method, system, and storage medium for improving RPC access efficiency, relating to the technical field of remote procedure calls and the technical field of remote procedure calls. The method for improving RPC access efficiency includes: a client and a server each allocate memory through a CPU and generate a handle to mark the memory; the client writes input data to be processed into its own allocated memory, uses the CPU to send an RPC control flow to the server, and exchanges handle information through a kernel module of the kernel layer for data transmission; the server accesses the input data based on the handle information to perform heterogeneous calculations, writes the calculation results into its own allocated memory, uses the CPU to send an RPC control flow to the client, and exchanges handle information through a kernel module of the kernel layer for data transmission; the client accesses the calculation results based on the handle information. The present application separates the control flow and data flow of the RPC access process, and the CPU only participates in the transmission of control flow data, thereby significantly improving the transmission efficiency of valid data during the RPC access process.

Description

Technical Field

[0001] The present application relates to the field of remote procedure call technology, and in particular to a method, system and storage medium for improving RPC access efficiency. Background Art

[0002] Remote Procedure Call (RPC) is a computer communication protocol that allows a program to call a procedure or function in another address space (typically on another computer) as if it were a local procedure or function. RPC enables different components in a distributed system to communicate and collaborate with each other.

[0003] In heterogeneous computing, there is usually a need for cross-domain and cross-chip RPC access to heterogeneous computing power. Figure 1 As shown, taking RPC remote call NPU heterogeneous computing power inference as an example, the CPU on the left uses the GPU's data computing power to preprocess data, and then remotely accesses the remote NPU heterogeneous computing power for model deployment and data inference.

[0004] However, in traditional RPC usage methods, the input and output data of the NPU need to be transferred through the CPU. In other words, data transmission requires deep involvement of the CPU and involves multiple memory copies from CPU memory to device memory, which will greatly reduce the efficiency of RPC access to heterogeneous computing power. Summary of the Invention

[0005] The present application provides a method, system and storage medium for improving RPC access efficiency, which separates the control flow and data flow of the RPC access process. The CPU only participates in the transmission of control flow data, greatly improving the transmission efficiency of valid data during the RPC access process.

[0006] In a first aspect, an embodiment of the present application provides a method for improving RPC access efficiency, the method for improving RPC access efficiency comprising:

[0007] The client and server each allocate memory through the CPU and generate a handle to mark the memory;

[0008] The client writes the input data to be processed into its own allocated memory, uses the CPU to send the RPC control flow to the server, and exchanges handle information through the kernel module in the kernel layer for data transmission;

[0009] The server accesses the input data based on the handle information to perform heterogeneous calculations, writes the calculation results into its own allocated memory, and uses the CPU to send the RPC control flow to the client, and exchanges the handle information through the kernel module of the kernel layer for data transmission;

[0010] The client accesses the calculation result based on the handle information.

[0011] In conjunction with the first aspect, in one embodiment, the client and the server each allocate memory through a CPU and generate a handle for marking the memory, including:

[0012] The client allocates a first memory through the CPU for storing the input data to be sent to the server and generates a first handle pointing to the first memory, and also allocates a second memory for storing the calculation result returned by the server and generates a second handle pointing to the second memory;

[0013] The server allocates a third memory through the CPU to store the input data sent by the client and generates a third handle pointing to the third memory, and also allocates a fourth memory to store the calculation result and generates a fourth handle pointing to the fourth memory.

[0014] In combination with the first aspect, in one embodiment, the client and the server each allocate memory in a shared memory area between the host and the device through the CPU, or directly from the device.

[0015] In conjunction with the first aspect, in one embodiment, when the CPU is used to send an RPC control flow to the server, and handle information is exchanged through the kernel module of the kernel layer for data transmission:

[0016] If it is a cross-domain scenario, the client's input data is transmitted through SHM shared memory, and the server directly accesses the client's first memory through the first handle passed by the client;

[0017] If it is a cross-chip scenario, the memory address is located through the first handle and the third handle, and the DMA controller is used to directly move the input data in the first memory of the client to the third memory of the server.

[0018] In conjunction with the first aspect, in one embodiment, when the CPU is used to send an RPC control flow to the client, and handle information is exchanged through the kernel module of the kernel layer for data transmission:

[0019] If it is a cross-domain scenario, the calculation result of the server is transmitted through SHM shared memory, and the client directly accesses the fourth memory of the server through the fourth handle passed by the server;

[0020] If it is a cross-chip scenario, the memory address is located through the second handle and the fourth handle, and the calculation result in the fourth memory of the server is directly moved to the second memory of the client using the DMA controller.

[0021] In a second aspect, an embodiment of the present application provides a system for improving RPC access efficiency, wherein the system for improving RPC access efficiency includes a client and a server;

[0022] The client and the server each allocate memory through the CPU and generate a handle to mark the memory;

[0023] The client is used to write the input data to be processed into its own allocated memory, use the CPU to send the RPC control flow to the server, and exchange handle information through the kernel module of the kernel layer to perform data transmission;

[0024] The server accesses the input data based on the handle information to perform heterogeneous calculations, writes the calculation results into its own allocated memory, uses the CPU to send the RPC control flow to the client, and exchanges the handle information through the kernel module of the kernel layer for data transmission;

[0025] The client accesses the calculation result based on the handle information.

[0026] In conjunction with the second aspect, in one embodiment, the client and the server each allocate memory through a CPU and generate a handle for marking the memory, including:

[0027] The client allocates a first memory through the CPU for storing the input data to be sent to the server and generates a first handle pointing to the first memory, and further allocates a second memory for storing the calculation result returned by the server and generates a second handle pointing to the second memory;

[0028] The server allocates a third memory through the CPU to store the input data sent by the client and generates a third handle pointing to the third memory, and also allocates a fourth memory to store the calculation result and generates a fourth handle pointing to the fourth memory.

[0029] In conjunction with the second aspect, in one embodiment, when the CPU is used to send an RPC control flow to the server, and handle information is exchanged through the kernel module of the kernel layer for data transmission:

[0030] If it is a cross-domain scenario, the client's input data is transmitted through SHM shared memory, and the server directly accesses the client's first memory through the first handle passed by the client;

[0031] If it is a cross-chip scenario, the memory address is located through the first handle and the third handle, and the DMA controller is used to directly move the input data in the first memory of the client to the third memory of the server.

[0032] In conjunction with the second aspect, in one embodiment, when the CPU is used to send an RPC control flow to the client, and handle information is exchanged through the kernel module of the kernel layer for data transmission:

[0033] If it is a cross-domain scenario, the calculation result of the server is transmitted through SHM shared memory, and the client directly accesses the fourth memory of the server through the fourth handle passed by the server;

[0034] If it is a cross-chip scenario, the memory address is located through the second handle and the fourth handle, and the calculation result in the fourth memory of the server is directly moved to the second memory of the client using the DMA controller.

[0035] In a third aspect, an embodiment of the present application provides a device for improving RPC access efficiency, wherein the device for improving RPC access efficiency includes a processor, a memory, and a program for improving RPC access efficiency stored in the memory and executable by the processor, wherein when the program for improving RPC access efficiency is executed by the processor, the steps of the above-mentioned method for improving RPC access efficiency are implemented.

[0036] In a fourth aspect, a computer-readable storage medium stores a program for improving RPC access efficiency, wherein when the program for improving RPC access efficiency is executed by a processor, the steps of the above-mentioned method for improving RPC access efficiency are implemented.

[0037] The beneficial effects of the technical solutions provided in the embodiments of the present application include at least:

[0038] The method for improving RPC access efficiency in the present application is as follows: the client and the server each allocate memory through the CPU and generate a handle to mark the memory; the client writes the input data to be processed into the memory allocated by itself, uses the CPU to send the RPC control flow to the server, and exchanges handle information through the kernel module of the kernel layer for data transmission; the server accesses the input data based on the handle information to perform heterogeneous calculations, and writes the calculation results into the memory allocated by itself, and uses the CPU to send the RPC control flow to the client, and exchanges handle information through the kernel module of the kernel layer for data transmission; the client accesses the calculation results based on the handle information.

[0039] The transport layer of this application separates the control flow and data flow in the RPC access process by interacting with the kernel module of the kernel layer. The CPU only participates in the transmission of control flow data. Compared with traditional RPC (GRPC), it greatly improves the transmission efficiency of effective data in the RPC access process. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 Schematic diagram of RPC remote call to NPU;

[0041] Figure 2 A flowchart of an embodiment of a method for improving RPC access efficiency according to the present application;

[0042] Figure 3 A structural block diagram of an embodiment of a system for improving RPC access efficiency according to the present application;

[0043] Figure 4 This is a diagram showing the data flow for this application. DETAILED DESCRIPTION

[0044] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0045] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0046] In a first aspect, an embodiment of the present application provides a method for improving RPC access efficiency.

[0047] In one embodiment, referring to Figure 2 , Figure 2 This is a flow chart of an embodiment of a method for improving RPC access efficiency in this application. Figure 2 As shown, methods for improving RPC access efficiency include:

[0048] S1. The client and server each allocate memory through the CPU and generate a handle to mark the memory;

[0049] S2. The client writes the input data to be processed into its own allocated memory, uses the CPU to send the RPC control flow to the server, and exchanges handle information through the kernel module of the kernel layer for data transmission;

[0050] S3. The server accesses the input data based on the handle information to perform heterogeneous computing, writes the computing results into its own allocated memory, and uses the CPU to send the RPC control flow to the client, and exchanges the handle information through the kernel module of the kernel layer for data transmission;

[0051] S4. The client accesses the calculation result based on the handle information.

[0052] Therefore, the present application separates the control flow and data flow of the RPC access process so that the CPU only participates in the transmission of control flow data, thereby greatly improving the transmission efficiency of valid data in the RPC access process.

[0053] Combine Figure 3 and Figure 4 As shown, the above steps are further explained below:

[0054] The entire process in this application can be divided into three stages: initialization stage, input data transmission stage (Client->Server), and output data transmission stage (Server->Client).

[0055] 1. Initialization phase (memory allocation and handle binding):

[0056] Client side:

[0057] a. Allocate two blocks of memory in the shared memory area between the host and the device (or allocate directly from the device):

[0058] The first memory, also known as the input package memory, is used to store input data to be sent to the server for processing.

[0059] The second memory, Output Package Memory, is used to store the calculation results returned by the server.

[0060] It is worth noting that the host refers to the CPU and its associated memory system, and the device refers to heterogeneous computing hardware and its private memory (such as accelerators such as GPU / NPU / VPU).

[0061] b. Generate handles for these two blocks of memory:

[0062] The first handle, Input Package Handle: points to the handle of the first memory on the client side.

[0063] The second handle, Output Package Handle: points to the handle of the second memory on the client side.

[0064] c. Bind the first handle Input Package Handle to the input queue (Input Queue) of the local heterogeneous hardware driver on the client side.

[0065] d. Bind the second handle, Output Package Handle, to the output queue (Output Queue) of the local heterogeneous hardware driver on the client side.

[0066] Server side:

[0067] a. Also allocate two blocks of memory in the shared memory area between the host and the device (or directly from the device):

[0068] The third memory, Input Package Memory: is used to receive input data sent by the client.

[0069] The fourth memory, Output Package Memory, is used to store the results of heterogeneous hardware calculations on the server side.

[0070] b. Generate handle:

[0071] The third handle, Input Package Handle: points to the handle of the third memory on the server side.

[0072] The fourth handle, Output Package Handle: points to the handle of the fourth memory on the server side.

[0073] c. Bind the third handle, Input Package Handle, to the input queue of the local heterogeneous hardware driver on the server side.

[0074] d. Bind the fourth handle, Output Package Handle, to the output queue (Output Queue) of the local heterogeneous hardware driver on the server side.

[0075] Control flow interaction (handle exchange):

[0076] The client and server exchange handle information with each other through control flow. Specifically:

[0077] The client sends its Input Package Handle and Output Package Handle to the server.

[0078] The server sends its Input Package Handle and Output Package Handle to the client.

[0079] In this way, both parties know the memory location of the other party's data (referenced by the handle).

[0080] It is worth noting that the Handles (software-layer memory identifiers) allocated by the client and server cannot be directly recognized by heterogeneous hardware (GPU / NPU, etc.) because the hardware requires the use of device physical addresses or IOVA (I / O Virtual Address).

[0081] In this embodiment, a kernel module, specifically a SEMM kernel module (SELinux Measure Module), is added to the kernel layer, which supports the acquisition and conversion of handles during cross-domain and cross-chip PCIE, TCP, UDP, and SHM transmission at the transport layer.

[0082] Specifically, the SEMM module converts Handle into:

[0083] In the same domain scenario, the physical address is directly mapped to the shared memory (for access by local heterogeneous hardware);

[0084] Cross-chip scenario: Convert to the DMA operable address of the target device (such as PCIE Endpoint address).

[0085] 2. Input data transmission phase (Client -> Server):

[0086] The client writes the input data to be processed directly into the Input Package Memory allocated by itself.

[0087] Then, data is transmitted according to the transmission scenario (cross-domain or cross-chip):

[0088] a. Cross-Domain scenario (using shared memory SHM):

[0089] Since the client and server share memory, the server can directly access the client's Input Package Memory through the Input Package Handle passed by the client without copying data.

[0090] b. Cross-Chip (using PCIE or TCP / UDP):

[0091] The DMA controller (PCIE DMA or ETH DMA) moves data from the client's Input Package Memory directly to the server's Input Package Memory. The memory address is located using the handles exchanged between the two parties.

[0092] The server-side heterogeneous hardware driver retrieves the Input Package Handle from its own input queue (this Handle points to the local Input Package Memory on the server side. In a cross-chip scenario, this memory already stores the data transferred from the client side), and then uses this handle to directly access the input data for heterogeneous computing.

[0093] 3. Output data transmission phase (Server ->Client):

[0094] After the server-side heterogeneous hardware completes the calculation, the calculation results are directly written into the OutputPackage Memory allocated by the server.

[0095] Then, data transmission is performed according to the transmission scenario:

[0096] a. Cross-Domain scenario (using shared memory SHM):

[0097] The client side directly accesses the result data in the Output Package Memory on the server side through the Output Package Handle passed by the server side, without copying.

[0098] b. Cross-Chip (using PCIE or TCP / UDP):

[0099] The DMA controller directly transfers the result data in the server's Output Package Memory to the client's Output Package Memory. Again, the CPU does not need to participate in the memory copy.

[0100] The client-side heterogeneous hardware driver retrieves the OutputPackage Handle from its own output queue (this Handle points to the client-side local Output Package Memory, where the result data transferred from the server is already stored in the cross-chip scenario), and then uses the handle to directly access the result data.

[0101] It is worth noting that, in this embodiment, the handle is a reference to a memory address, and the corresponding memory area can be accessed through the handle. In the initialization phase, the two parties exchange handles so that the other party can locate the memory that needs to be accessed.

[0102] In addition, each end (Client and Server) has an input queue and an output queue for storing handles. The driver takes the handle from the input queue to obtain input data and puts the handle of output data into the output queue.

[0103] In the entire data flow, the control flow is processed by the CPU, while the data flow (actual data writing and transmission) does not go through the CPU memory copy, thereby improving efficiency.

[0104] To summarize, the method for improving RPC access efficiency in the present application is that the client and server each allocate memory through the CPU and generate a handle to mark the memory; the client writes the input data to be processed into the memory allocated by itself, uses the CPU to send the RPC control flow to the server, and exchanges handle information through the kernel module of the kernel layer for data transmission; the server accesses the input data based on the handle information for heterogeneous calculations, and writes the calculation results into the memory allocated by itself, and uses the CPU to send the RPC control flow to the client, and exchanges handle information through the kernel module of the kernel layer for data transmission; the client accesses the calculation results based on the handle information.

[0105] The transport layer of this application separates the control flow and data flow in the RPC access process by interacting with the kernel module of the kernel layer. The CPU only participates in the transmission of control flow data. Compared with traditional RPC (GRPC), it greatly improves the transmission efficiency of effective data in the RPC access process.

[0106] In a second aspect, an embodiment of the present application also provides a system for improving RPC access efficiency.

[0107] In one embodiment, referring to Figure 3 , Figure 3 This is a structural diagram of an embodiment of a system for improving RPC access efficiency. Figure 3 As shown, the system for improving RPC access efficiency includes a client and a server.

[0108] The client and the server each allocate memory through the CPU and generate a handle to mark the memory;

[0109] The client is used to write the input data to be processed into its own allocated memory, use the CPU to send the RPC control flow to the server, and exchange handle information through the kernel module of the kernel layer to perform data transmission;

[0110] The server accesses the input data based on the handle information to perform heterogeneous calculations, writes the calculation results into its own allocated memory, uses the CPU to send the RPC control flow to the client, and exchanges the handle information through the kernel module of the kernel layer for data transmission;

[0111] The client accesses the calculation result based on the handle information.

[0112] Furthermore, in one embodiment, the client and the server each allocate memory through a CPU and generate a handle for marking the memory, including:

[0113] The client allocates a first memory through the CPU for storing the input data to be sent to the server and generates a first handle pointing to the first memory, and further allocates a second memory for storing the calculation result returned by the server and generates a second handle pointing to the second memory;

[0114] The server allocates a third memory through the CPU to store the input data sent by the client and generates a third handle pointing to the third memory, and also allocates a fourth memory to store the calculation result and generates a fourth handle pointing to the fourth memory.

[0115] Furthermore, in one embodiment, the client and the server each allocate memory directly from the device through the CPU in a memory area shared by the host and the device.

[0116] Furthermore, in one embodiment, when the CPU is used to send an RPC control flow to the server, and handle information is exchanged through the kernel module of the kernel layer for data transmission:

[0117] If it is a cross-domain scenario, the client's input data is transmitted through SHM shared memory, and the server directly accesses the client's first memory through the first handle passed by the client;

[0118] If it is a cross-chip scenario, the memory address is located through the first handle and the third handle, and the DMA controller is used to directly move the input data in the first memory of the client to the third memory of the server.

[0119] Furthermore, in one embodiment, when the CPU is used to send an RPC control flow to the client, and handle information is exchanged through the kernel module of the kernel layer for data transmission:

[0120] If it is a cross-domain scenario, the calculation result of the server is transmitted through SHM shared memory, and the client directly accesses the fourth memory of the server through the fourth handle passed by the server;

[0121] If it is a cross-chip scenario, the memory address is located through the second handle and the fourth handle, and the calculation result in the fourth memory of the server is directly moved to the second memory of the client using the DMA controller.

[0122] In a third aspect, an embodiment of the present application also provides a readable storage medium.

[0123] The readable storage medium of the present application stores a program for improving RPC access efficiency, wherein when the program for improving RPC access efficiency is executed by a processor, the steps of the method for improving RPC access efficiency as described above are implemented.

[0124] Among them, the method implemented when the RPC access efficiency improvement program is executed can refer to the various embodiments of the method for improving RPC access efficiency in this application, and will not be repeated here.

[0125] It should be noted that the serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0126] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, or the part that contributes to the existing technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above and includes a number of instructions for enabling a terminal device to execute the methods described in each embodiment of this application.

[0127] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit the "first", "second" and "third" to different types.

[0128] In the description of the embodiments of this application, the words "exemplary," "for example," or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary," "for example," or "for example" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete manner.

[0129] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

[0130] In some processes described in the embodiments of the present application, multiple operations or steps are included that appear in a specific order. However, it should be understood that these operations or steps may not be performed in the order in which they appear in the embodiments of the present application or may be performed in parallel. The sequence numbers of the operations are only used to distinguish between different operations, and the sequence numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations or steps may be performed in sequence or in parallel, and these operations or steps may be combined.

[0131] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

[0132] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for improving RPC access efficiency, characterized in that: The method for improving RPC access efficiency includes: The client and server each allocate memory through the CPU and generate a handle to mark the memory; The client writes the input data to be processed into its own allocated memory, uses the CPU to send the RPC control flow to the server, and exchanges handle information through the kernel module in the kernel layer for data transmission; The server accesses the input data based on the handle information to perform heterogeneous calculations, writes the calculation results into its own allocated memory, and uses the CPU to send the RPC control flow to the client, and exchanges the handle information through the kernel module of the kernel layer for data transmission; The client accesses the calculation result based on the handle information.

2. The method for improving RPC access efficiency according to claim 1, wherein: The client and the server each allocate memory through the CPU and generate a handle to mark the memory, including: The client allocates a first memory through the CPU for storing the input data to be sent to the server and generates a first handle pointing to the first memory, and also allocates a second memory for storing the calculation result returned by the server and generates a second handle pointing to the second memory; The server allocates a third memory through the CPU to store the input data sent by the client and generates a third handle pointing to the third memory, and also allocates a fourth memory to store the calculation result and generates a fourth handle pointing to the fourth memory.

3. The method for improving RPC access efficiency according to claim 1 or 2, wherein: The client and the server each use the CPU to share a memory area between the host and the device, or directly allocate memory from the device.

4. The method for improving RPC access efficiency according to claim 2, wherein: When using the CPU to send RPC control flow to the server and exchanging handle information through the kernel module in the kernel layer for data transmission: If it is a cross-domain scenario, the client's input data is transmitted through SHM shared memory, and the server directly accesses the client's first memory through the first handle passed by the client; If it is a cross-chip scenario, the memory address is located through the first handle and the third handle, and the DMA controller is used to directly move the input data in the first memory of the client to the third memory of the server.

5. The method for improving RPC access efficiency according to claim 2, wherein: When using the CPU to send RPC control flow to the client and exchanging handle information through the kernel module in the kernel layer for data transmission: If it is a cross-domain scenario, the calculation result of the server is transmitted through SHM shared memory, and the client directly accesses the fourth memory of the server through the fourth handle passed by the server; If it is a cross-chip scenario, the memory address is located through the second handle and the fourth handle, and the calculation result in the fourth memory of the server is directly moved to the second memory of the client using the DMA controller.

6. A system for improving RPC access efficiency, characterized by: The system for improving RPC access efficiency includes a client and a server; The client and the server each allocate memory through the CPU and generate a handle to mark the memory; The client is used to write the input data to be processed into its own allocated memory, use the CPU to send the RPC control flow to the server, and exchange handle information through the kernel module of the kernel layer to perform data transmission; The server accesses the input data based on the handle information to perform heterogeneous calculations, writes the calculation results into its own allocated memory, uses the CPU to send the RPC control flow to the client, and exchanges the handle information through the kernel module of the kernel layer for data transmission; The client accesses the calculation result based on the handle information.

7. The system for improving RPC access efficiency according to claim 6, wherein: The client and the server each allocate memory through the CPU and generate a handle to mark the memory, including: The client allocates a first memory through the CPU for storing the input data to be sent to the server and generates a first handle pointing to the first memory, and further allocates a second memory for storing the calculation result returned by the server and generates a second handle pointing to the second memory; The server allocates a third memory through the CPU to store the input data sent by the client and generates a third handle pointing to the third memory, and also allocates a fourth memory to store the calculation result and generates a fourth handle pointing to the fourth memory.

8. The system for improving RPC access efficiency according to claim 7, wherein: When using the CPU to send RPC control flow to the server and exchanging handle information through the kernel module in the kernel layer for data transmission: If it is a cross-domain scenario, the client's input data is transmitted through SHM shared memory, and the server directly accesses the client's first memory through the first handle passed by the client; If it is a cross-chip scenario, the memory address is located through the first handle and the third handle, and the DMA controller is used to directly move the input data in the first memory of the client to the third memory of the server.

9. The system for improving RPC access efficiency according to claim 7, wherein: When using the CPU to send RPC control flow to the client and exchanging handle information through the kernel module in the kernel layer for data transmission: If it is a cross-domain scenario, the calculation result of the server is transmitted through SHM shared memory, and the client directly accesses the fourth memory of the server through the fourth handle passed by the server; If it is a cross-chip scenario, the memory address is located through the second handle and the fourth handle, and the calculation result in the fourth memory of the server is directly moved to the second memory of the client using the DMA controller.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a program for improving RPC access efficiency, wherein when the program for improving RPC access efficiency is executed by a processor, the steps of the method for improving RPC access efficiency according to any one of claims 1 to 5 are implemented.

Images