Implementation method and system of a remote invocation framework

Abstract

The application discloses an implementation method and system of a remote calling framework, and belongs to the computer field. The method comprises the following steps: a host end generates a calling or a request carrying a command required to be executed by a device end, and sends the calling or the request to a device driver; the device driver determines a saving address of a parameter corresponding to the command in a shared memory after receiving the calling or the request, encapsulates the parameter into a message, and then sends the message to a hardware message queue of the device end; firmware of the device end obtains the command required to be executed by the device end by analyzing the message, obtains the corresponding parameter from the shared memory according to the saving address of the parameter, so that the host end is sent a completion notification carrying a storage address of an execution result in the shared memory after the command is executed and the execution result is obtained; and the host end obtains the execution result from the shared memory after receiving the completion notification. The application can fully exert the function of the device end, reduce the load of the host end, and improve the efficiency of the computer system.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and system for implementing a remote invocation framework. Background Technology

[0002] Modern computer systems consist of a host and device sides, which are connected through standard communication interfaces such as PCIe. Typically, the computation process occurs on the host side, while the device side primarily supports the host in completing the computation, such as providing the data required for the calculation.

[0003] In this process, the host communicates with the device through a driver, which is a special program that enables communication between the computer and the device. It is equivalent to a hardware interface, and the host operating system can only control the operation of the device through this interface.

[0004] However, as the functionality of devices in computer systems becomes increasingly powerful, the corresponding device drivers also become more complex. Traditional computing methods increase the load on the host, preventing the devices from fully utilizing their capabilities. Therefore, improving the efficiency of both the host and device sides has become a new development trend. Summary of the Invention

[0005] To address the problem that existing technologies cannot fully utilize the functions of the device side, the purpose of this invention is to provide a method and system for implementing a remote invocation framework.

[0006] To achieve the above objectives, the technical solution of the present invention is as follows:

[0007] In a first aspect, the present invention provides a method for implementing a remote invocation framework, the method comprising,

[0008] The host generates a call or request and sends it to the device driver, the call or request carrying the command that the device needs to execute;

[0009] After receiving the call or request, the device driver determines the storage address in shared memory of the parameters corresponding to the command;

[0010] The device driver encapsulates the call or request and the storage address of the parameters into a message;

[0011] The device driver sends the message to the hardware message queue on the device side so that the firmware on the device side can obtain the message from the hardware message queue, and obtain the command that the device side needs to execute by parsing it. After executing the command and obtaining the execution result, the execution result is stored in the shared memory and a completion notification is sent to the host side. The completion notification carries the storage address of the execution result in the shared memory.

[0012] The host receives the completion notification and retrieves the execution result from the shared memory according to the storage address carried in the completion notification.

[0013] Secondly, the present invention also provides a method for implementing a remote invocation framework, the method comprising,

[0014] The firmware on the device side retrieves messages from the hardware message queue on the device side, and the messages are sent to the hardware message queue by the host side through the device driver;

[0015] The firmware parses the command that the device needs to execute and the storage address of the corresponding parameters in shared memory from the message;

[0016] The firmware retrieves the parameters from the shared memory based on the storage address, and then executes the command based on the parameters to obtain the execution result;

[0017] The firmware stores the execution result in the shared memory and sends a completion notification to the host. The completion notification carries the storage address of the execution result in the shared memory, so that the host can retrieve the execution result from the shared memory according to the storage address.

[0018] Thirdly, the present invention also provides a method for implementing a remote invocation framework, the method comprising:

[0019] The host generates a call or request and sends it to the device driver, the call or request carrying the command that the device needs to execute;

[0020] After receiving the call or request, the device driver determines the storage address in shared memory of the parameters corresponding to the command;

[0021] The device driver encapsulates the call or request and the storage address of the parameters into a message;

[0022] The device driver sends the message to the hardware message queue on the device side;

[0023] The firmware on the device side retrieves messages from the hardware message queue on the device side, and the messages are sent to the hardware message queue by the host side through the device driver;

[0024] The firmware parses the command that the device needs to execute and the storage address of the corresponding parameters in shared memory from the message;

[0025] The firmware retrieves the parameters from the shared memory based on the storage address, and then executes the command based on the parameters to obtain the execution result;

[0026] The firmware stores the execution result in the shared memory and sends a completion notification to the host, the completion notification carrying the storage address of the execution result in the shared memory;

[0027] The host receives the completion notification and retrieves the execution result from the shared memory according to the storage address carried in the completion notification.

[0028] Furthermore, the messages have priorities, and the firmware traverses the hardware message queue to retrieve messages in descending order of priority.

[0029] Preferably, each time the firmware reads a message from the hardware message queue, the priority of the message stored in the hardware message queue is increased by a preset value.

[0030] Preferably, the firmware reads messages of equal priority in chronological order.

[0031] Furthermore, the hardware message queue is configured with multiple groups, and each group is configured with an independent memory page table.

[0032] Preferably, the host and the device are connected via a PCIe bus.

[0033] Furthermore, the device encapsulates the reported events or states and corresponding data in a message and reports it to the host via an interrupt.

[0034] Fourthly, the present invention also provides an implementation system for a remote invocation framework, comprising:

[0035] On the host side, the host side is used to generate a call or request, the call or request carrying a command that the device side needs to execute;

[0036] A device driver, which is installed on the host and used to enable communication between the host and the device, is used to receive the call or request and determine the storage address in shared memory of the parameter corresponding to the command carried in the call or request, and then encapsulate the call or request and the storage address of the parameter into a message and send it to the hardware message queue of the device.

[0037] On the device side, the device side includes firmware and a hardware message queue. The hardware message queue is used to store messages sent by the device driver. The firmware is used to retrieve the messages from the hardware message queue and parse the commands that the device side needs to execute from the messages, as well as the storage address of the parameters corresponding to the commands. The firmware is also used to retrieve the parameters from shared memory according to the storage address and then execute the commands according to the parameters to obtain the execution result. The firmware is also used to save the execution result in the shared memory and then send a completion notification carrying the storage address of the execution result in the shared memory to the host side.

[0038] And shared memory, which is communicatively connected to the host and the device, and is used to store the parameters and the execution results.

[0039] Preferably, multiple devices are configured, and each of the multiple devices communicates with the host through a corresponding device driver.

[0040] By adopting the above technical solution, since the host end encapsulates the command and the corresponding parameter storage address into a message through the device driver before sending it to the hardware message queue of the device end, the device end can use its firmware to parse out the command to be executed from the message, obtain the parameters according to the parameter storage address, and then execute the command according to the parameters and obtain the execution result. This realizes remote calling of the device end's functions, fully utilizes the device end's functions, reduces the load on the host end, and improves the efficiency of the computer system. Attached Figure Description

[0041] Figure 1 This is a flowchart of the method according to Embodiment 1 of the present invention;

[0042] Figure 2 This is a flowchart of the method in Embodiment 2 of the present invention;

[0043] Figure 3 This is a flowchart of the method in Embodiment 3 of the present invention;

[0044] Figure 4 This is a schematic diagram of the system structure in Embodiment 8 of the present invention. Detailed Implementation

[0045] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings. It should be noted that these descriptions are for the purpose of aiding understanding the present invention, but do not constitute a limitation thereof. Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0046] It should be noted that in the description of this invention, the terms "upper", "lower", "left", "right", "front", "rear", etc., indicate the orientation or positional relationship based on the description of the structure of this invention shown in the accompanying drawings. They are only for the convenience of describing this invention and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0047] The terms "first" and "second" in this technical solution are merely designations for corresponding structures that are identical or similar, or that perform similar functions. They do not represent an arrangement of the importance of these structures, nor do they imply any ranking, comparison of size, or other meaning.

[0048] Furthermore, unless otherwise explicitly specified and limited, the terms "installation" and "connection" should be interpreted broadly. For example, a connection can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two structures. Those skilled in the art can understand the specific meaning of the above terms in this invention by considering the overall concept of the invention and the specific context of the solution.

[0049] Example 1

[0050] An implementation method for a remote invocation framework, which is applied on the host side, such as... Figure 1 As shown, the method includes the following steps:

[0051] S1, the host generates a call or request and sends it to the device driver. This call or request carries the command that the device needs to execute; the host typically generates the call or request based on business requirements.

[0052] For example, the host calls the device driver interface: Get Device Version().

[0053] S2, after receiving a call or request, the device driver determines the storage address in shared memory of the parameters corresponding to the command that the device needs to execute.

[0054] Shared memory typically refers to a large amount of memory in a multiprocessor computer system that can be accessed by different central processing units (CPUs). Shared memory is a communication method between multiple processes in Unix, commonly used for communication between multiple processes within a single program, and also for transferring information between multiple programs.

[0055] In this embodiment, the shared memory is used to communicate with both the host and the device simultaneously, so that both the host and the device can access the shared memory and the data stored in the shared memory can be used by both the host and the device.

[0056] S3, the device driver encapsulates the call or request and the storage address of the parameters into a message.

[0057] For example, a device driver encapsulates a call or request into a message containing the command GET_DEVICE_VERSION and the address in shared memory where the corresponding parameters are stored.

[0058] S4, the device driver sends the encapsulated message to the device's hardware message queue so that the device's firmware can retrieve the message from the hardware message queue. Then, the firmware parses the message to obtain the command that the device needs to execute (i.e., GET_DEVICE_VERSION) and the storage address of the corresponding parameters in shared memory. Then, the firmware retrieves the corresponding parameters from shared memory using the storage address of the parameters and executes the command accordingly. After executing the command, the firmware obtains the execution result, stores the execution result in shared memory, and then sends a completion notification to the host, which carries the storage address of the execution result in shared memory.

[0059] S5, the host receives the completion notification and retrieves the execution result from the shared memory according to the storage address carried in the completion notification. At this point, the host completes the remote function call to the device.

[0060] As can be seen, the method provided in this embodiment enables the load on the host side to be implemented through the device side.

[0061] Example 2

[0062] An implementation method for a remote invocation framework, applied to the device side, such as... Figure 2 As shown, the method includes the following steps:

[0063] S11, the device firmware retrieves a message from the device's hardware message queue, which is sent to the hardware message queue by the host through the device driver.

[0064] The message contains the command that the device needs to execute and the address of the corresponding parameters stored in shared memory.

[0065] S12, the firmware parses the command that the device needs to execute and the storage address of the corresponding parameters in shared memory from the obtained message.

[0066] S13, the firmware retrieves the corresponding parameters from the shared memory based on the storage address, and then executes the command based on the parameters to obtain the execution result.

[0067] S14, the firmware saves the execution result in shared memory and sends a completion notification to the host. The completion notification carries the storage address of the execution result in shared memory so that the host can retrieve the execution result from shared memory according to the storage address.

[0068] Example 3

[0069] A method for implementing a remote procedure call (RPC) framework is provided. This method is applied to a host and a device, which are connected and communicate through standard interfaces, such as PCIe, standard serial port (RS232), Ethernet interface, USB interface, and wireless interface.

[0070] like Figure 3 As shown, the method includes the following steps:

[0071] S21, the host generates a call or request and sends it to the device driver. This call or request carries the command that the device needs to execute; the host typically generates the call or request based on business requirements.

[0072] For example, the host calls the device driver interface: Get Device Version().

[0073] S22, after receiving a call or request, the device driver determines the storage address in shared memory of the parameters corresponding to the command that the device needs to execute.

[0074] Shared memory typically refers to a large amount of memory in a multiprocessor computer system that can be accessed by different central processing units (CPUs). Shared memory is a communication method between multiple processes in Unix. This method is commonly used for communication between multiple processes within a single program, but multiple programs can also exchange information through shared memory.

[0075] In this embodiment, the shared memory is used to communicate with both the host and the device simultaneously, so that both the host and the device can access the shared memory and the data stored in the shared memory can be used by both the host and the device.

[0076] S23, the device driver encapsulates the call or request and the storage address of the parameters into a message.

[0077] For example, the device driver encapsulates a call or request into a message containing the command GET_DEVICE_VERSION and the address in shared memory where the corresponding parameters are stored.

[0078] S24, the device driver sends the encapsulated message to the device's hardware message queue.

[0079] S25, the device firmware retrieves messages from the device's hardware message queue, and the messages are sent to the hardware message queue by the host through the device driver.

[0080] S26, the firmware parses the command that the device needs to execute and the storage address of the corresponding parameters in shared memory from the message it obtains.

[0081] S27, the firmware retrieves the corresponding parameters from the shared memory based on the storage address of the parameters in the shared memory, and then executes the above command based on the parameters to obtain the execution result.

[0082] S28, the firmware saves the execution result in shared memory and sends a completion notification to the host, which carries the storage address of the execution result in shared memory.

[0083] S29, the host receives the completion notification and retrieves the execution result from the shared memory according to the storage address carried in the completion notification.

[0084] It's understandable that the host can implement both synchronous and asynchronous calls. In synchronous calls, after sending a call or request to the device, the host waits for the execution result from the device before proceeding to the next iteration. In asynchronous calls, after sending a call or request to the device, the relevant processes enter a sleep state until the execution results are returned to the host, at which point the processes are awakened to continue execution. It's important to note that synchronous and asynchronous calls are not necessarily related to processes; both synchronous and asynchronous calls can occur within the same process.

[0085] Example 4

[0086] In any of the above embodiments, the host typically sends multiple calls or requests to the device over a period of time. The device can execute the commands carried in the received messages in chronological order. Alternatively, the host can set priorities for the calls or requests, such as 256 levels from 0 to 255, so that the messages stored in the hardware message queue have priorities. This allows the device firmware to process the messages in descending order of priority after comparing the priority information of the calls or requests in each message when it finds multiple messages in the hardware message queue. Typically, the firmware traverses the hardware message queue and retrieves messages in descending order of priority.

[0087] Example 5

[0088] Based on the solution provided in Embodiment 4, when there are multiple messages in the hardware message queue and they are configured with priorities, in order to prevent low-priority messages from never being executed, this embodiment further includes the following steps in configuring the above method:

[0089] Each time the firmware reads a message from the hardware message queue, the priority of the message stored in the hardware message queue increases by a preset value.

[0090] The preferred preset value is 1, which means that after the firmware reads a message each time, the priority level of the messages that still exist in the hardware message queue increases by 1. This setting allows low-priority messages to obtain higher priority after waiting for a certain period of time, thereby avoiding the situation where low-priority messages cannot be executed.

[0091] In a preferred embodiment, for messages with the same priority in the hardware message queue, the firmware reads messages of the same priority in chronological order.

[0092] Example 6

[0093] In practical applications, in any of the above embodiments, the hardware message queue on the device side supports multiple groups, and each group is configured with an independent memory page table. This configuration allows commands serving the same process to be stored in the same group and share a single memory page table, thus enabling convenient process / page table switching on the device side. It is also understood that the hardware message queue's support for multiple group configurations is not limited to whether the host is single-process or multi-process.

[0094] Taking the acquisition of the device version number on the host side as an example, the host's mobilization process is explained as follows:

[0095] 1. Create a task process on the host and obtain its process ID (XPID);

[0096] 2. Within this process, the host calls the driver interface: GetDeviceVersion(), and sets the priority of this call to x (any value between 0 and 255);

[0097] 3. The driver encapsulates the call or request into a message Q, which contains the command: GET_DEVICE_VERSION, process ID (XPID), call sequence number, and a memory address for storing call parameters. This address points to a region in shared memory. The message is then sent to a specific group in the hardware message queue on the device side, which is bound to the host process by the process ID (XPID).

[0098] 4. During synchronous calls, the host waits for the device to return its status; during asynchronous calls, the host first puts the process to sleep and wakes it up when the device returns its status.

[0099] 5. The device traverses each group of the hardware message queue, retrieves and executes messages; when switching groups, it also switches to the corresponding memory page table.

[0100] 6. When traversing message Q, if message Q has the highest priority X in the same group, then retrieve the message, parse out the command: GET_DEVICE_VERSION, the call sequence number, and the address of the corresponding parameters in shared memory, and at the same time, increase the priority of other messages in the group by one level.

[0101] 7. The device executes the instruction, saves the result to shared memory, and sends a completion notification to the host.

[0102] Example 7

[0103] In any of the above embodiments, the device encapsulates the reported events or statuses and corresponding data in a message and reports it to the host via an interrupt, so that the host can perform corresponding operations after receiving the message. At the same time, the device actively reports the status or events when an error occurs.

[0104] Example 8

[0105] An implementation system of a remote invocation framework, such as Figure 4 As shown, it includes the host side, device driver, device side, firmware, hardware message queue, and shared memory.

[0106] The host is used to generate calls or requests, which carry the commands that the device needs to execute.

[0107] The device driver is installed on the host side and is used to enable communication between the host side and the device side. The device driver is used to receive calls or requests and determine the storage address in shared memory of the parameters corresponding to the commands carried in the call or request. Then, it encapsulates the call or request and the storage address of the parameters into a message and sends it to the hardware message queue on the device side.

[0108] The device side includes the aforementioned firmware and hardware message queue. The hardware message queue stores messages sent by the device driver. The firmware retrieves messages from the hardware message queue and parses them to extract the command to be executed by the device and the storage address of the corresponding parameters. The firmware also retrieves the parameters from shared memory based on the storage address, executes the command based on the parameters, and obtains the execution result. Finally, the firmware stores the execution result in shared memory and sends a completion notification to the host, carrying the storage address of the execution result in shared memory.

[0109] The shared memory communicates with both the host and the device, and is used to store parameters and execution results.

[0110] The host side is also used to configure priority information for calls or requests, so as to: enable the firmware to traverse the hardware message queue and retrieve messages in descending order of priority; increase the priority of the messages stored in the hardware message queue by a preset value each time the firmware reads a message from the hardware message queue; and enable the firmware to read messages of equal priority in chronological order.

[0111] The hardware message queue is configured with multiple groups, and each group has its own independent memory page table.

[0112] In another embodiment, multiple devices are configured, each communicating with the host through a corresponding device driver (wherein, when devices are identical, their corresponding device drivers are also identical). The host communicates with each device through different shared memory, or alternatively, through the same shared memory. This configuration allows tasks from the host to be distributed to more devices for execution, thereby further improving system efficiency.

[0113] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings, but the present invention is not limited to the described embodiments. For those skilled in the art, various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention, and these variations still fall within the protection scope of the present invention.

Claims

1. A method for implementing a remote invocation framework, characterized in that: The method includes, The host generates a call or request and sends it to the device driver, the call or request carrying the command that the device needs to execute; After receiving the call or request, the device driver determines the storage address in shared memory of the parameters corresponding to the command; The device driver encapsulates the call or request and the storage address of the parameters into a message; The device driver sends the message to the hardware message queue on the device side so that the firmware on the device side can obtain the message from the hardware message queue, and obtain the command that the device side needs to execute by parsing it. After executing the command and obtaining the execution result, the execution result is stored in the shared memory and a completion notification is sent to the host side. The completion notification carries the storage address of the execution result in the shared memory. The host receives the completion notification and retrieves the execution result from the shared memory according to the storage address carried in the completion notification.

2. A method for implementing a remote invocation framework, characterized in that: The method includes, The firmware on the device side retrieves messages from the hardware message queue on the device side, and the messages are sent to the hardware message queue by the host side through the device driver; The firmware parses the command that the device needs to execute and the storage address of the corresponding parameters in shared memory from the message; The firmware retrieves the parameters from the shared memory based on the storage address, and then executes the command based on the parameters to obtain the execution result; The firmware stores the execution result in the shared memory and sends a completion notification to the host. The completion notification carries the storage address of the execution result in the shared memory, so that the host can retrieve the execution result from the shared memory according to the storage address.

3. A method for implementing a remote invocation framework, characterized in that: The method includes: The host generates a call or request and sends it to the device driver, the call or request carrying the command that the device needs to execute; After receiving the call or request, the device driver determines the storage address in shared memory of the parameters corresponding to the command; The device driver encapsulates the call or request and the storage address of the parameters into a message; The device driver sends the message to the hardware message queue on the device side; The firmware on the device side retrieves messages from the hardware message queue on the device side, and the messages are sent to the hardware message queue by the host side through the device driver; The firmware parses the command that the device needs to execute and the storage address of the corresponding parameters in shared memory from the message; The firmware retrieves the parameters from the shared memory based on the storage address, and then executes the command based on the parameters to obtain the execution result; The firmware stores the execution result in the shared memory and sends a completion notification to the host, the completion notification carrying the storage address of the execution result in the shared memory; The host receives the completion notification and retrieves the execution result from the shared memory according to the storage address carried in the completion notification.

4. The method according to any one of claims 1-3, characterized in that: The messages have priorities, and the firmware traverses the hardware message queue to retrieve messages in descending order of priority.

5. The method according to claim 4, characterized in that: Each time the firmware reads a message from the hardware message queue, the priority of the message stored in the hardware message queue increases by a preset value.

6. The method according to claim 4, characterized in that: The firmware reads messages of equal priority in chronological order.

7. The method according to any one of claims 1-3, characterized in that: The hardware message queue is configured with multiple groups, and each group is configured with an independent memory page table.

8. The method according to any one of claims 1-3, characterized in that: The host and the device are connected via a PCIe bus.

9. The method according to any one of claims 1-3, characterized in that: The device encapsulates the reported events or states and corresponding data in a message and reports them to the host via an interrupt.

10. A system for implementing a remote invocation framework, characterized in that: include: On the host side, the host side is used to generate a call or request, the call or request carrying a command that the device side needs to execute; A device driver, which is installed on the host and used to enable communication between the host and the device, is used to receive the call or request and determine the storage address in shared memory of the parameter corresponding to the command carried in the call or request, and then encapsulate the call or request and the storage address of the parameter into a message and send it to the hardware message queue of the device. On the device side, the device side includes firmware and a hardware message queue. The hardware message queue is used to store messages sent by the device driver. The firmware is used to retrieve the messages from the hardware message queue and parse the commands that the device side needs to execute from the messages, as well as the storage address of the parameters corresponding to the commands. The firmware is also used to retrieve the parameters from shared memory according to the storage address and then execute the commands according to the parameters to obtain the execution result. The firmware is also used to save the execution result in the shared memory and then send a completion notification carrying the storage address of the execution result in the shared memory to the host side. And shared memory, which is communicatively connected to the host and the device, and is used to store the parameters and the execution results.

11. The system according to claim 10, characterized in that: The device is configured with multiple devices, and each of the multiple devices communicates with the host through a corresponding device driver.

Images