Method and apparatus for offloading microcode program, and related product

Abstract

Disclosed are a method and apparatus for offloading a microcode program, and a related product, relating to the technical field of computers. In embodiments of the present application, a first static microcode program in firmware of a DPU is provided, and the first static microcode program is used for implementing dynamic offloading of any microcode program of a host to the DPU. Moreover, the association relationship between the first static microcode program and first indication information is expanded. Correspondingly, the host is equipped with a corresponding user-oriented first interface, and a user can trigger offloading of a microcode program by means of the first interface. On this basis, by simply carrying first indication information and a microcode program to be offloaded in a packet, a host can dynamically offload the microcode program to a DPU during operation of the DPU. Therefore, the embodiments of the present application can implement dynamic offloading of the microcode program to the DPU during operation of the DPU, so that a certain microcode program can be dynamically modified during operation of the DPU, without interrupting service corresponding to another microcode program.

Description

Method, device and related products for uninstalling microcode program

[0001] This application claims priority to Chinese patent application No. 202311440063.4 filed on October 31, 2023, entitled “Methods, devices and related products for unloading microcode programs,” the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of computer technology, and in particular to a method, device, and related products for uninstalling a microcode program. Background Art

[0003] In order to reduce the data processing pressure of the central processing unit (CPU) of the host, the host can be connected to a data processing unit (DPU) to offload some data-centric microcode programs of the host to the DPU.

[0004] In related technology, when the DPU is powered on, all microcode programs to be offloaded to the DPU are compiled and packaged into firmware, which is then burned into the DPU. This facilitates subsequent host calls to the microcode programs on the DPU. If a microcode program needs to be modified, all microcode programs are recompiled and packaged into firmware after the modification, and then re-burned into the DPU when the DPU is powered on. This results in significant service interruptions during service upgrades.

[0005] Summary of the Invention

[0006] The present invention provides a method, device, and computer storage medium for unloading microcode programs, which can dynamically unload microcode programs from a DPU during operation, thereby dynamically modifying a microcode program during operation without interrupting the services of other microcode programs. The technical solution is as follows:

[0007] In a first aspect, a method for unloading a microcode program is provided, which is applied to a data processing chip DPU, wherein the firmware of the DPU includes a first static microcode program; the method includes: the DPU receives a first message from a host, the first message carries first indication information, microcode data, and a logical address of the microcode data in the DPU, the microcode data being data after compiling the program body of the target microcode program to be unloaded; in response to the first indication information, the DPU executes the first static microcode program, the first static microcode program being used to convert the logical address into a physical address, and unload the microcode data to a storage location corresponding to the physical address.

[0008] The embodiment of the present application provides a first static microcode program deployed in the firmware of the DPU, and the first static microcode program is used to dynamically unload any microcode program of the host to the DPU. And the association relationship between the first static microcode program and the first indication information is expanded. Based on this, the host can dynamically unload the microcode program to the DPU during the operation of the DPU by simply carrying the first indication information and the microcode program to be unloaded in the message. Therefore, the embodiment of the present application can realize the dynamic unloading of the microcode program to the DPU during the operation of the DPU, so that a certain microcode program can be dynamically modified during the operation of the DPU without the need for service interruption corresponding to other microcode programs.

[0009] Based on the method provided in the first aspect, in a possible implementation manner, the DPU stores an association relationship between the first indication information and the first static microcode program.

[0010] By pre-storing the association between the first indication information and the first static microcode program, the DPU can quickly determine that the first static microcode program needs to be executed when receiving a message including the first indication information, thereby improving the execution efficiency of the DPU.

[0011] Based on the method provided in the first aspect, in one possible implementation, the DPU stores address conversion rules, which are used to indicate the mapping relationship between logical addresses and physical addresses; and the first static microcode program is used to convert the logical address into a physical address based on the address conversion rules.

[0012] By storing the address translation rules locally, the execution efficiency of the first static microcode program can be improved.

[0013] Based on the method provided in the first aspect, in a possible implementation manner, the DPU receives a first message from the host, including: the DPU receives the first message from the host through a serial computer bus or a network port.

[0014] The method provided in the embodiment of the present application is not only applicable to the local host but also to the remote host, thereby improving the application flexibility of the embodiment of the present application.

[0015] Based on the method provided in the first aspect, in one possible implementation, the firmware of the DPU includes a second static microcode program; after the DPU executes the first static microcode program, the method further includes: the DPU receives a second message from the host, the second message carries second indication information, parameters and logical addresses required to execute the target microcode program; in response to the second indication information, the DPU executes the second static microcode program, the second static microcode program is used to obtain microcode data based on the logical address, and determine the execution result based on the microcode data and parameters; the DPU returns the execution result to the host.

[0016] In order to avoid the limited number of microcode programs that can be unloaded on the DPU due to the space limitations of the DPU registers, an embodiment of the present application further provides a second static microcode program deployed in the DPU firmware. The second static microcode program is used to call any microcode program on the DPU. The association relationship between the second static microcode program and the second indication information is expanded in the microcode table. Based on this, the host can call any microcode program on the DPU by simply carrying the second indication information and the relevant information of the microcode program to be called in the message, without having to store the correspondence between each microcode program and the indication information in the microcode table of the DPU register.

[0017] Based on the method provided in the first aspect, in a possible implementation manner, the DPU stores an association relationship between the second indication information and the second static microcode program.

[0018] By pre-storing the association between the second indication information and the second static microcode program, the DPU can quickly determine that the second static microcode program needs to be executed when receiving a message including the second indication information, thereby improving the execution efficiency of the DPU.

[0019] Based on the method provided in the first aspect, in one possible implementation, the firmware of the DPU includes a third static microcode program; the method also includes: the DPU receives a third message from the host, the third message carries third indication information and a user identifier of the target microcode program; in response to the third indication information, the DPU executes a third static microcode program, the third static microcode program is used to register a function identifier based on the user identifier of the target microcode program; the DPU returns the function identifier to the host; wherein the second message also carries a function identifier, the second static microcode program is used to generate a function pointer based on the function identifier and the logical address, and obtain microcode data based on the function pointer.

[0020] This embodiment of the present application also provides a third static microcode program deployed in the DPU's firmware. The third static microcode program is used to register a microcode program on the host. The microcode table also extends the association between the third static microcode program and third indication information. Based on this, the host can register a microcode program on the DPU simply by including the third indication information and information related to the microcode program to be registered in a message.

[0021] Based on the method provided in the first aspect, in a possible implementation manner, the DPU stores an association relationship between the third indication information and the third static microcode program.

[0022] By pre-storing the association between the third indication information and the third static microcode program, when the DPU receives a message including the third indication information, it can quickly determine that the third static microcode program needs to be executed, thereby improving the execution efficiency of the DPU.

[0023] In a second aspect, a method for uninstalling a microcode program is provided. The method is applied to a host, the host is connected to a data processing chip DPU, and the host includes a first interface. The method includes:

[0024] The host obtains an uninstall request triggered by a user through a first interface, where the uninstall request carries a user identifier of a target microcode program and a program body of the target microcode program;

[0025] The host obtains a logical address allocated to the target microcode program based on a user identifier of the target microcode program;

[0026] The host sends a first message to the DPU, where the first message carries first indication information, microcode data, and a logical address, where the microcode data is data compiled from a program body of a target microcode program;

[0027] The first indication information is used to instruct the DPU to execute a first static microcode program, and the first static microcode program is used to convert a logical address into a physical address and unload the microcode data to a storage location corresponding to the physical address.

[0028] An embodiment of the present application provides a first static microcode program deployed in the firmware of the DPU. The first static microcode program is used to dynamically unload any microcode program of the host to the DPU. The association relationship between the first static microcode program and the first indication information is expanded in the microcode table. Accordingly, the host is configured with a corresponding first user-oriented interface, and the user can trigger the unloading of the microcode program through the first interface. Based on this, the host can dynamically unload the microcode program to the DPU during the operation of the DPU by simply carrying the first indication information and the microcode program to be unloaded in the message.

[0029] Based on the method provided in the second aspect, in a possible implementation, the host also includes a second interface; the method also includes: the host obtains a call request triggered by the user through the second interface, the call request carries the user identifier of the target microcode program and the parameters required to execute the target microcode program; the host determines the logical address assigned to the target microcode program based on the user identifier of the target microcode program; the host sends a second message to the DPU, the second message carries second indication information, parameters and logical address, the second indication information is used to instruct the DPU to execute a second static microcode program, the second static microcode program is used to obtain microcode data based on the logical address, and determine the execution result based on the microcode data and parameters; the host receives the execution result returned by the DPU.

[0030] The embodiment of the present application also provides a second static microcode program deployed in the firmware of the DPU 20, and the second static microcode program is used to call the microcode program on the DPU 20. And the association relationship between the second static microcode program and the second indication information is extended in the microcode table. Accordingly, the host is configured with a corresponding second user-oriented interface, and the user can trigger the call of the microcode program through the second interface. Based on this, the host can call the microcode program on the DPU 20 by simply carrying the second indication information and the relevant information of the microcode program to be called in the message. In this way, there is no need to store the indication information corresponding to each microcode program in all the microcode programs that have been uninstalled in the microcode table of the DPU 20, thereby avoiding the limited number of microcode programs that can be uninstalled on the DPU 20 due to the space limitation of the registers of the DPU 20.

[0031] Based on the method provided in the second aspect, in a possible implementation, the host also includes a third interface; the method also includes: the host obtains a registration request triggered by the user through the third interface, the registration request carries the user identifier of the target microcode program and the size of the target microcode program; the host allocates a logical address to the target microcode program based on the size of the target microcode program, and establishes an association relationship between the user identifier and the logical address of the target microcode program.

[0032] In an embodiment of the present application, the user may first register the target microcode program to be uninstalled on the host so that the host can allocate a logical address to the target microcode program when registering the target microcode program, thereby improving the efficiency of subsequent uninstallation of the target microcode program.

[0033] Based on the method provided in the second aspect, in a possible implementation, the method also includes: the host sends a third message to the DPU, the third message carries third indication information and a user identifier of the target microcode program, the third indication information is used to instruct the DPU to execute a third static microcode program, and the third static microcode program is used to register a function identifier based on the user identifier of the target microcode program; the host receives the function identifier returned by the DPU; wherein, the second message carries the function identifier.

[0034] The embodiment of the present application also provides a third static microcode program deployed in the firmware of the DPU. The third static microcode program is used to register a microcode program on the host. The association between the third static microcode program and the third indication information is expanded in the microcode table. Accordingly, the host is configured with a corresponding third user-oriented interface, through which the user can trigger the registration of the microcode program. Based on this, the host can register a microcode program on the DPU simply by carrying the third indication information and relevant information of the microcode program to be registered in the message.

[0035] In a third aspect, a device for uninstalling a microcode program is provided. The device for uninstalling a microcode program has the function of implementing the method for uninstalling a microcode program described in the first aspect. The device for uninstalling a microcode program includes at least one module, which is used to implement the method for uninstalling a microcode program described in the first aspect.

[0036] In a fourth aspect, a device for uninstalling a microcode program is provided, wherein the device for uninstalling a microcode program has the function of implementing the method for uninstalling a microcode program in the second aspect. The device for uninstalling a microcode program includes at least one module, wherein the at least one module is used to implement the method for uninstalling a microcode program in the second aspect.

[0037] In a fifth aspect, a DPU is provided, comprising a processor and a memory, wherein the memory is configured to store a program that supports the DPU in executing the method for unloading a microcode program provided in the first aspect, and to store data related to implementing the method for unloading a microcode program provided in the first aspect. The processor is configured to execute the program stored in the memory.

[0038] In a sixth aspect, a host is provided, comprising a processor and a memory, the memory being configured to store a program that supports the host in executing the method for unloading a microcode program provided in the second aspect, and to store data related to implementing the method for unloading a microcode program provided in the second aspect. The processor is configured to execute the program stored in the memory.

[0039] In the seventh aspect, a computer-readable storage medium is provided, in which instructions are stored. When the computer-readable storage medium is run on a computer, the computer executes the method for unloading the microcode program described in the first aspect, or the method for unloading the microcode program described in the second aspect.

[0040] In an eighth aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to execute the method for unloading the microcode program described in the first aspect, or enables the computer to execute the method for unloading the microcode program described in the second aspect.

[0041] The technical effects obtained by the corresponding technical means in the above-mentioned second to eighth aspects are similar to the technical effects obtained by the corresponding technical means in the first or second aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] FIG1 is a schematic diagram of the architecture of a system for unloading microcode programs provided in an embodiment of the present application;

[0043] FIG2 is a schematic diagram of the architecture of a DPU provided in an embodiment of the present application;

[0044] 3 is a schematic diagram of an address conversion rule between a pointer address and a physical address provided in an embodiment of the present application;

[0045] FIG4 is a flow chart of a method for uninstalling a microcode program provided in an embodiment of the present application;

[0046] FIG5 is a flow chart of another method for unloading a microcode program provided by an embodiment of the present application;

[0047] FIG6 is a flow chart of another method for uninstalling a microcode program provided in an embodiment of the present application;

[0048] FIG7 is a schematic diagram of an interface of a first interface provided in an embodiment of the present application;

[0049] FIG8 is a schematic diagram of an interface of a third interface provided in an embodiment of the present application;

[0050] FIG9 is a schematic diagram of the format of a third message provided in an embodiment of the present application;

[0051] FIG10 is a schematic diagram of the format of a first message provided in an embodiment of the present application;

[0052] FIG11 is a schematic diagram of another flow chart of calling a microcode program according to an embodiment of the present application;

[0053] FIG12 is a schematic diagram of an interface of a second interface provided in an embodiment of the present application;

[0054] FIG13 is a schematic diagram of the format of a second message provided in an embodiment of the present application;

[0055] FIG14 is a flow chart of a process of uninstalling a microcode program and calling a microcode program according to an embodiment of the present application;

[0056] FIG15 is a schematic diagram of a performance comparison provided by an embodiment of the present application;

[0057] FIG16 is a schematic diagram of a process for designing a key for a target microcode program according to an embodiment of the present application;

[0058] FIG17 is a schematic diagram of an extended function table provided in an embodiment of the present application;

[0059] FIG18 is a schematic structural diagram of a device for unloading a microcode program provided in an embodiment of the present application;

[0060] FIG19 is a schematic structural diagram of another device for unloading a microcode program provided in an embodiment of the present application;

[0061] FIG20 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application;

[0062] Figure 21 is a structural diagram of a DPU provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0064] Before explaining the embodiments of the present application, the application scenarios of the embodiments of the present application are first introduced.

[0065] In CPU-centric data processing architectures, the CPU is responsible for processing all network packets and data requests, making it a bottleneck in computer processing performance. Subsequently, technologies such as the Data Plane Development Kit (DPDK) and Remote Direct Memory Access (RDMA) were introduced, and bypassing the host CPU for data processing became a significant trend. In the "CPU + Graphics Processing Unit (GPU) + DPU" data processing architecture, the DPU leverages the advantages of a data processing center to offload and accelerate critical network, storage, security, and virtualization tasks, freeing up CPU computing power to focus on resource management and task scheduling, significantly improving resource utilization and processing efficiency within the data processing architecture. However, the addition of these new processing units presents significant challenges to both user and programming models. Designing a new data processing architecture that is highly scalable, user- and developer-friendly, and high-performance has become a pressing challenge.

[0066] In some scenarios, remote procedure call (RPC) technology is used in data processing architectures that include CPUs and DPUs to dynamically offload microcode programs, such as user loads, from the CPU to the DPU. RPC is a technology that uses network protocols to communicate between different processes. Its advantage is that it makes cross-language and cross-platform interactions easier and more convenient. Through RPC, a client can call a procedure on a remote server just like calling a local procedure, without having to worry about the underlying communication details. This offers the advantages of flexibility and scalability.

[0067] For example, developers implement an RPC server running on the DPU side and an RPC client running on the host side. Through the agreed application interface, the RPC client on the host side remotely calls the RPC server that is listening on the DPU in the form of a function call. After the RPC server completes the specified task, it returns the execution result to the RPC client. The remote call request and return value are packaged into network messages according to the RPC protocol, and are transmitted and parsed between the RPC client and the RPC server through the application interface on the host side and the application interface on the DPU side. Among them, the RPC model requires that the RPC server must be running and listening before the RPC client sends any remote call request.

[0068] In the aforementioned technologies, on the one hand, the interaction between the RPC client and the RPC server must be completed through bilateral operations, which causes latency issues. On the other hand, the communication capabilities of the RPC protocol are limited, resulting in a limited number of microcode programs that can be offloaded to the DPU.

[0069] In other scenarios, DPUs based on many-core processor architectures are applied to data processing architectures. Among them, DPUs based on many-core processor architectures integrate a variety of hardware accelerators, including smart memory, to achieve flexible data packet processing and task offloading. Users and developers can write microcode programs for many cores on a general CPU programming framework and use the provided hardware accelerator library to implement various business development and designs on the DPU. After development is completed, all microcode programs are compiled and packaged into firmware and burned into the DPU's flash memory. When the DPU is powered on, all microcode programs are loaded into the smart memory according to the mapping relationship between the logical address (the logical address indicates the location of the firmware in the flash memory) and the physical address (indicates the location in the smart memory). The smart memory can be, for example, a state-full smart memory (SMF).

[0070] Each specific microcode program is bound to the message type in a message or request. The message type keyword and the microcode program entry address are stored in specific registers on the DPU. When the DPU receives a message or request, the hardware parses the message type in the message or request and obtains the microcode program entry address. After waking up the microcode thread and passing the entry address and other metadata to the microcode thread, control is transferred to the microcode thread. The microcode thread fetches and executes instructions from the microcode program sequentially, starting from the entry address.

[0071] The above solution relies entirely on hardware. While improving system performance, it also introduces challenges with flexibility and scalability. For example, if a microcode program needs to be modified, all microcode programs must be recompiled and packaged into firmware after the modification, and then re-burned into the DPU after the DPU is powered on. This results in lengthy service interruptions during the upgrade, in some scenarios lasting up to 20 minutes to an hour.

[0072] Based on this, an embodiment of the present application provides a method for unloading a microcode program, which can dynamically unload the microcode program into the DPU during the operation of the DPU, thereby dynamically modifying a microcode program during the operation of the DPU to avoid interruption of services running on the DPU due to updating the microcode program.

[0073] The following explains the system, method and related products for uninstalling microcode programs provided in the embodiments of the present application.

[0074] FIG1 is a schematic diagram of the architecture of a system for uninstalling microcode programs provided by an embodiment of the present application. As shown in FIG1 , the system includes a local host 10 , a DPU 20 , and a remote host 30 .

[0075] The local host 10 and the DPU 20 are connected to communicate via a serial computer bus. For example, the local host 10 and the DPU 20 communicate via a high-speed serial computer expansion bus (Peripheral Component Interconnect Express, PCIe), which ensures local communication latency and bandwidth.

[0076] The remote host 30 and the DPU 20 are connected to each other via a network port for communication. For example, the remote host 30 and the DPU 20 can communicate via the network port based on the RDMA protocol, thereby enabling the remote host 30 to remotely call the DPU 20 based on the unilateral RDMA protocol, thereby improving application performance.

[0077] As shown in Figure 1, the remote host 30 can directly initiate an access request to the DPU 20 through a unilateral RDMA operation. The access request carries user data. After the network processors (NPs) on the DPU 20 process the user data using a user defined function (UDF), the data can be returned directly to the remote host 30 accordingly.

[0078] In an embodiment of the present application, the local host 10 or the remote host 30 can dynamically offload the microcode program to the DPU 20 using the method provided in the embodiment of the present application while the DPU 20 is running, and remotely call the microcode program in the DPU 20. As shown in Figure 1, the microcode program exemplarily includes a key-value pair search (KV Lookup) application, a user-defined function (UDF) application, and a filter application. Based on this, the system shown in Figure 1 can also be referred to as a system based on the dynamic offloads development kit (DODK).

[0079] In this embodiment of the present application, DPU 20 is based on a many-core processor. DPU 20 interacts with the host through a microcode table, also known as a microcode function call table, which is stored in registers of DPU 20. The microcode table is used to record indication information (also known as message types) corresponding to static microcode programs in DPU 20's firmware. The host can use the indication information carried in the message to notify DPU 20 of the static microcode program currently to be executed.

[0080] To enable dynamic unloading of microcode programs from the DPU 20 during operation, an embodiment of the present application provides a first static microcode program deployed in the firmware of the DPU 20. The first static microcode program is used to dynamically unload any microcode program from the host to the DPU 20. The association between the first static microcode program and the first indication information is expanded in the microcode table. Accordingly, the host is configured with a corresponding first user-oriented interface, through which the user can trigger the unloading of the microcode program. Based on this, the host can dynamically unload the microcode program to the DPU 20 during operation simply by carrying the first indication information and the microcode program to be unloaded in a message.

[0081] Furthermore, an embodiment of the present application also provides a second static microcode program deployed in the firmware of the DPU 20, and the second static microcode program is used to call the microcode program on the DPU 20. And the association relationship between the second static microcode program and the second indication information is extended in the microcode table. Accordingly, the host is configured with a corresponding second user-oriented interface, and the user can trigger the call of the microcode program through the second interface. Based on this, the host can call the microcode program on the DPU 20 by simply carrying the second indication information and the relevant information of the microcode program to be called in the message. In this way, there is no need to store the indication information corresponding to each microcode program in all the microcode programs that have been uninstalled in the microcode table of the DPU 20, thereby avoiding the limited number of microcode programs that can be uninstalled on the DPU 20 due to the space limitation of the registers of the DPU 20.

[0082] In addition, embodiments of the present application further provide a third static microcode program deployed in the firmware of the DPU 20. This third static microcode program is used to register a microcode program on the host. The association between the third static microcode program and third indication information is expanded in the microcode table. Accordingly, the host is configured with a corresponding third user-facing interface, through which users can trigger microcode program registration. Based on this, the host can register a microcode program on the DPU 20 simply by including the third indication information and relevant information about the microcode program to be registered in a message.

[0083] As shown in Figure 1, the DPU 20 also includes a hardware ucode thread scheduler. The hardware scheduler manages and maintains instructions and data on the DPU. It also leverages the operational logic within the DPU 20 to implement dynamic remote calls to microcode programs without disrupting the DPU 20's existing hardware and microcode wakeup process. Instructions can be understood as specific operations required for computation, such as addition, subtraction, multiplication, or division, and data can be understood as the data used during computation.

[0084] To facilitate subsequent understanding, the functions of the three static microcode programs deployed in the firmware of the DPU 20 provided in the embodiment of the present application are first explained.

[0085] (1) The third static microcode program: function_register(func name).

[0086] The user triggers a registration request through the third interface. The registration request carries the user identifier of the target microcode program to be uninstalled (labeled as func name) and the size of the target microcode program. After the host receives the registration request, it allocates a logical address for the target microcode program based on the size of the target microcode program and adds the association between the allocated logical address and the user identifier of the target microcode program to the local function table.

[0087] When assigning logical addresses, the host ensures that the logical addresses of the static microcode program already burned into the DPU firmware will not be overwritten, thereby allowing the original static microcode program in the DPU to continue to execute normally. For example, the host can maintain a base address, which can be understood as the end address of the logical addresses of the static microcode program already burned into the DPU. Based on this, the host can start allocating addresses from this base address each time it assigns an address to the target microcode program to be uninstalled, thereby ensuring that the assigned address does not overwrite the logical address of the static microcode program already burned into the DPU.

[0088] In addition, after the host obtains the registration request, it can also send a third message to the DPU. The third message carries third indication information and the user identifier of the target microcode program to instruct the DPU to execute a third static microcode program. The third microcode program registers a unique function identifier for the target microcode program.

[0089] (2) The first static microcode program: function_offload (func name).

[0090] The user triggers an uninstall request through the first interface. The uninstall request carries the user identifier of the target microcode program to be uninstalled and the program body of the target microcode program. Based on the uninstall request, the host searches the function table for the allocated logical address and, through a cross-compiler, programs the program body of the target microcode program into instructions executable by the microcode thread. For ease of subsequent understanding, the compiled instructions are referred to as microcode data. The host sends a first message to the DPU. The first message carries first indication information, microcode data, and a logical address, causing the host to execute the first static microcode program based on the first indication information.

[0091] (3) The second static microcode program: function_exec(func_lva, func_code).

[0092] The user triggers a call request through the second interface. The call request carries the user identifier of the target microcode program and the parameters required to execute the target microcode program (labeled as func_code). Based on the call request, the host searches the function table for the allocated logical address and function identifier, where the function identifier + logical address can be called a function pointer (labeled as func_lva), and sends a second message to the DPU. The second message carries the second indication information, the logical address and function identifier, and the parameters, so that the host executes the second static microcode program based on the second indication information.

[0093] Figure 2 is a schematic diagram of the architecture of a DPU provided in an embodiment of the present application. As shown in Figure 2, the DPU includes multiple processing cores, multiple SMFs, and a two-level cache (L2 cache). The multiple processing cores, the two-level cache, and the multiple SMFs communicate with each other via a ring bus. Figure 2 uses four SMFs as an example for illustration, and the embodiment of the present application does not limit the number of SMFs.

[0094] For example, as shown in Figure 2, each processing core includes a level 1 cache (L1 cache) and multiple microcode threads. Each microcode thread also includes a stack and single-port random access memory (SPRAM). The stack and SPRAM are used to store data, while the level 1 cache, level 2 cache, and SMF are used to store instructions. In other words, in this embodiment of the application, the DPU adopts a data-in-finger separation storage architecture.

[0095] Based on the above content, it can be seen that three static microcode programs are expanded in the DPU firmware. These static microcode programs are burned into the DPU firmware by the host side when the DPU is turned on.

[0096] In some embodiments, the implementation method of burning a static microcode program into the firmware of the DPU can be: after the host side completes the writing and creation of the static microcode program, all the static microcodes are compiled and packaged into firmware, and burned into the flash memory in the DPU. When the DPU is turned on, all the instructions in the firmware are read out of the flash memory and cross-written into the smart memory. At this time, the instructions complete a conversion from a logical address (offset in the flash memory) to a physical address (location in the smart memory), and at the same time, the logical address of the static microcode program and the indication information bound to it are loaded into the microcode table of the specified register. The indication information is also called the message type. During the operation of the DPU, when the hardware scheduler receives a message, it parses the indication information in the message, queries the register to determine the static microcode program to be executed, and writes the logical address of the static microcode program to be executed into its SPRAM before waking up the microcode thread. After being awakened, each microcode thread executes a common microcode segment. This segment converts the instruction address stored in SPRAM into a function pointer and directly jumps to it. The conversion of the instruction's logical address to the physical address is automatically performed by the L1 or L2 cache when a miss occurs. As shown in Figure 2, the hardware scheduler sequentially checks the L1 cache, L2 cache, and SMF to obtain the required instruction.

[0097] In addition, in an embodiment of the present application, in order to achieve dynamic unloading of the microcode program during the operation of the DPU, technicians can track and analyze the logical addresses of the instructions in the firmware (the addresses that the host can see) and the physical locations where they are stored after the DPU is powered on, thereby establishing a mapping rule between the logical addresses and physical addresses of the instructions in the DPU. In other words, the DPU stores an address conversion rule, which is used to indicate the mapping relationship between the logical address and the physical address, so that the first static microcode program converts the logical address of the target microcode program into a physical address based on the address conversion rule, thereby being able to unload the target microcode program based on the physical address.

[0098] Furthermore, in a data-and-finger separation architecture, when the target microcode program is unloaded, the data in the target microcode program can be directly stored in the stack and SPRAM corresponding to the corresponding thread. The instructions in the target microcode program need to determine the location of the SMF to be stored according to the address translation rules. Based on this, the address translation rules can be understood as the mapping relationship between the logical address and the physical address of the SMF.

[0099] In some embodiments, the instructions in the microcode program are stored in the SMF in an array in units of 16 bytes, so the physical address of the instruction can be represented by the linear table descriptor in the SMF. Figure 3 is a schematic diagram of the address conversion rules between the logical address and the physical address provided by an embodiment of the present application. Among them, GPA represents the logical address of the instruction. The physical address is represented as a combination of mem_index_hi, mem_index_lo, smf_id and offset. Mem_index_hi and mem_index_lo represent the index numbers of the linear table in the SMF, smf_id represents the unique identifier of the SMF, and offset represents the offset within 16 bytes in the SMF linear table.

[0100] Based on the above address conversion rules, during the operation of the DPU, the host can trigger a memory access instruction, and the memory access instruction carries a logical address, so that the DPU can find the corresponding physical address based on the logical address, and access (such as write and modify) the instruction in the SMF through the physical address, thereby realizing dynamic modification of instructions while the DPU is running.

[0101] In addition, considering the limited resources in the DPU, the SMF can store public data required for system and business operations in addition to instructions, so a general interface for reading and writing can be opened to the microcode thread. The following is an example of an interface for the DPU to access data or instructions stored in the SMF through parameters such as mem_index_hi and mem_index_lo:

[0102] smf_lt_extend_cachemod_store_without_gpa(sp_addr,cmd_hdr,cmd_2nd_4bytes,mem_index_h,mem_index_l,key_size,byte_mask_enable,srctagl).

[0103] Through the above interface, technicians can store executable instructions in the specified physical location of the DPU's SMF in advance, and obtain their logical addresses through the address conversion rules shown in Figure 3. Subsequently, technicians can use this logical address to trigger dynamic modifications to the instructions in the SMF.

[0104] It should be noted that Figure 2 is used to illustrate the architecture of the DPU provided in the embodiment of the present application. The embodiment of the present application does not limit the architecture of the DPU, and will not be illustrated one by one here.

[0105] Figure 4 is a flow chart of a method for uninstalling a microcode program provided by an embodiment of the present application. The method is exemplarily applied to the host side of the system shown in Figure 1. As shown in Figure 4, the method includes the following steps.

[0106] Step 401: The host obtains an uninstallation request triggered by a user through a first interface. The uninstallation request carries a user identifier of a target microcode program and a program body of the target microcode program.

[0107] Step 402: The host obtains a logical address allocated to the target microcode program based on the user identifier of the target microcode program.

[0108] Step 403: The host sends a first message to the DPU, where the first message carries first indication information, microcode data, and a logical address. The microcode data is data obtained by compiling the program body of the target microcode program. The first indication information is used to instruct the DPU to execute a first static microcode program, and the first static microcode program is used to convert the logical address into a physical address of the DPU and unload the microcode data to a storage location corresponding to the physical address.

[0109] An embodiment of the present application provides a first static microcode program deployed in the firmware of the DPU. The first static microcode program is used to dynamically offload any microcode program of the host to the DPU. The association relationship between the first static microcode program and the first indication information is expanded. Accordingly, the host is configured with a corresponding first user-oriented interface, through which the user can trigger the offloading of the microcode program. Based on this, the host can dynamically offload the microcode program to the DPU during the operation of the DPU by simply carrying the first indication information and the microcode program to be offloaded in the message.

[0110] FIG5 is a flow chart of another method for unloading a microcode program provided in an embodiment of the present application. The method is exemplarily applied to the DPU side of the system shown in FIG1. ​​As shown in FIG5, the method includes the following steps.

[0111] Step 501: The DPU receives a first message from the host. The first message carries first indication information, microcode data, and a logical address of the microcode data in the DPU. The microcode data is data compiled from the program body of the target microcode program to be uninstalled.

[0112] Step 502: In response to the first indication information, the DPU executes a first static microcode program, where the first static microcode program is used to convert a logical address into a physical address of the DPU and unload microcode data to a storage location corresponding to the physical address.

[0113] This embodiment of the present application provides a first static microcode program deployed in the DPU's firmware. This first static microcode program is used to dynamically offload any microcode program from the host to the DPU. The embodiment also expands the association between the first static microcode program and first indication information. Based on this, the host can dynamically offload the microcode program to the DPU while the DPU 20 is running simply by including the first indication information and the microcode program to be offloaded in a message.

[0114] FIG6 is a flow chart of another method for uninstalling a microcode program provided by an embodiment of the present application. The method is exemplarily applied to the system shown in FIG1. ​​As shown in FIG6, the method includes the following steps.

[0115] Step 601: The host obtains an uninstallation request triggered by a user through a first interface. The uninstallation request carries a user identifier of a target microcode program and a program body of the target microcode program.

[0116] The user identifier may be, for example, a name configured by the user for the target microcode program. The program body of the target microcode program carried in the uninstall request may be understood as the code corresponding to the target microcode program.

[0117] FIG7 is a schematic diagram of a first interface provided by an embodiment of the present application. As shown in FIG7 , when the host detects a user clicking on the "first interface" option on the display interface, a user identification input window and a program body input window are displayed, so that the user can trigger an uninstall request for the target microcode program based on these two windows.

[0118] Step 602: The host obtains a logical address allocated to the target microcode program based on the user identifier of the target microcode program.

[0119] When the host receives an unload request for the target microcode program, the host must first obtain the logical address assigned to the target microcode program in order to facilitate the subsequent DPU to unload the target microcode program according to the mapping rules between the logical address on the host side and the physical address on the DPU side. It should be noted that in the embodiment of the present application, the logical address specifically refers to the address in the flash memory of the DPU. Since this logical address is visible to the host, it is also called the logical address on the host side.

[0120] In some embodiments, the host may temporarily allocate a logical address to the target microcode program when obtaining an uninstall request for the target microcode program.

[0121] Optionally, in other embodiments, the user may first register the target microcode program to be uninstalled on the host, so that the host allocates a logical address to the target microcode program when registering the target microcode program, thereby improving the efficiency of subsequent uninstallation of the target microcode program.

[0122] For example, the implementation method for a user to register a target microcode program on a host can be: the host obtains a registration request triggered by the user through a third interface, and the registration request carries the user identifier of the target microcode program and the size of the target microcode program; the host allocates a logical address to the target microcode program based on the size of the target microcode program, and establishes an association relationship between the user identifier of the target microcode program and the logical address.

[0123] The allocated logical address illustratively includes a start address and an address length, and optionally may also include a start address and an end address.

[0124] FIG8 is a schematic diagram of a third interface provided in an embodiment of the present application. As shown in FIG8 , when the host detects a user clicking on the "third interface" option on the display interface, a user identification input window and a program size input window are displayed, allowing the user to trigger a registration request for the target microcode program based on these two windows.

[0125] In addition, after establishing the association between the user identifier and the logical address of the target microcode program, the host can also add the association between the user identifier and the logical address of the target microcode program to the local function table to facilitate subsequent query of the association from the function table.

[0126] Furthermore, considering that the target microcode program's user ID is typically a string, which is inconvenient for subsequent operations, the host can also register a function ID for the target program on the DPU. The function ID can, for example, be a two-digit number. This function ID can be used to uniquely identify the target microcode program during subsequent internal interactions between the host and DPU, improving interaction efficiency.

[0127] In some embodiments, the host registers a function identifier for the target program on the DPU as follows: the host sends a third message to the DPU, the third message carrying third indication information and a user identifier of the target microcode program; the DPU receives the third message from the host; in response to the third indication information, the DPU executes a third static microcode program, and the third static microcode program is used to register a function identifier based on the user identifier of the target microcode program; the DPU returns the function identifier to the host; and the host receives the function identifier returned by the DPU.

[0128] Optionally, the third message may also carry other information such as the size of the target microcode program.

[0129] FIG9 is a schematic diagram of the format of a third message provided in an embodiment of the present application. As shown in FIG9 , the sub-type field of the message sent by the host to the DPU carries the third indication information, and the data field carries the user identifier of the target microcode program and the size (ucode_size) of the target microcode program.

[0130] In Figure 9, the lines marked with DW are the header of the third message, where DW is the abbreviation for double word, indicating that each line has 4 bytes, a total of 32 bits. The lines marked with DATA are the data portion of the third message excluding the header.

[0131] In addition, the module type (module_type) value of the third message in Figure 9 indicates that this is a message sent by the host to the DPU. Based on the values ​​of the module type (module_type) and sub-type fields, the DPU can determine that the host currently needs to execute the third static microcode program, that is, it needs to register a microcode program. For the interpretation of the other fields in the message shown in Figure 9, please refer to the relevant standards and will not be explained here one by one.

[0132] In this scenario, the first message sent by the host to the DPU may carry the function identifier or may not carry the function identifier.

[0133] In addition, in response to the third indication information, the DPU executing the third static microcode program can be understood as: based on the third indication information, the DPU searches the microcode table for the static microcode program corresponding to the third indication information to obtain the third static microcode program.

[0134] In other words, the DPU stores the association between the third indication information and the third static microcode program. By pre-storing the association between the third indication information and the third static microcode program, the DPU can quickly determine whether the third static microcode program needs to be executed upon receiving a message including the third indication information, thereby improving the DPU's execution efficiency.

[0135] The DPU may execute the third static microcode program by, for example, waking up an idle microcode thread and passing information related to the third static microcode program, such as the logical address of the third static microcode program, to the microcode thread. The microcode thread then reads instructions from the third static microcode program based on the logical address of the third static microcode program and executes the read instructions to execute the third static microcode program.

[0136] In addition, after the host obtains the function identifier for the target microcode program, it can also add the function identifier to the association relationship between the user identifier and the logical address of the target microcode program in the function table, that is, create an association relationship between the user identifier, function identifier and logical address of the target microcode program in the function table, so that the subsequent host can quickly query the function identifier.

[0137] Step 603: The host sends a first message to the DPU. The first message carries first indication information, microcode data, and a logical address. The microcode data is data obtained by compiling the program body of the target microcode program.

[0138] Figure 10 is a schematic diagram of the format of a first message provided in an embodiment of the present application. As shown in Figure 10, the sub-type field of the message sent by the host to the DPU carries the first indication information, and the data field carries microcode data (ucode_segment_0) and a logical address (gpa_1).

[0139] Through the value of the module type (module_type) and the value of the subtype (sub-type) field, the DPU can determine that the host currently needs to execute the first static microcode program, that is, it needs to dynamically unload a microcode program.

[0140] Step 604: The DPU receives a first message from the host.

[0141] Based on the architecture shown in Figure 1, it can be seen that the DPU can receive the first message from the host via a serial computer bus or a network port. In other words, the method provided in the embodiment of the present application is applicable not only to the local host but also to the remote host, thereby increasing the application flexibility of the embodiment of the present application.

[0142] Step 605: In response to the first indication information, the DPU executes a first static microcode program, where the first static microcode program is used to convert the logical address into a physical address of the DPU and unload the microcode data to a storage location corresponding to the physical address.

[0143] In response to the first indication information, the DPU executes the first static microcode program, which can be understood as: based on the first indication information, the DPU searches the microcode table for the static microcode program corresponding to the first indication information to obtain the first static microcode program.

[0144] In other words, the DPU stores the association between the first indication information and the first static microcode program. By pre-storing the association between the first indication information and the first static microcode program, the DPU can quickly determine that the first static microcode program needs to be executed when receiving a message including the first indication information, thereby improving the execution efficiency of the DPU.

[0145] Optionally, in an embodiment of the present application, the DPU may also obtain the association relationship between the first indication information and the first static microcode program through other means, such as obtaining it from other network devices through the network, which will not be repeated here.

[0146] The DPU may execute the first static microcode program by, for example, waking up an idle microcode thread and passing information related to the first static microcode program, such as the logical address of the first static microcode program, to the microcode thread. The microcode thread then reads instructions from the first static microcode program based on the logical address of the first static microcode program and executes the instructions to execute the first static microcode program.

[0147] In addition, based on the foregoing content, it can be seen that the DPU in the embodiment of the present application adopts a storage structure with separated numbers and fingers. Therefore, the implementation method of converting the logical address into a physical address and unloading the microcode data to the storage location corresponding to the physical address can be, for example: converting the logical address into a physical address corresponding to the SMF, and unloading the instructions in the microcode data to the storage location of the SMF indicated by the physical address, unloading the data in the microcode data to the stack and SPRAM corresponding to the microcode thread, and establishing a correspondence between the logical address and the stack and SPRAM corresponding to the microcode thread, so as to facilitate the subsequent search for data in the microcode data based on the correspondence when calling the target microcode program.

[0148] In some embodiments, the DPU stores address translation rules that indicate a mapping relationship between logical addresses and physical addresses; the first static microcode program is configured to translate the logical addresses into physical addresses based on the address translation rules. By locally storing the address translation rules, the execution efficiency of the first static microcode program can be improved.

[0149] Optionally, the DPU may also obtain the address conversion rule through other means, which will not be described one by one here.

[0150] Optionally, after converting the logical address to a physical address, the DPU can return the physical address to the host. The host can then add the physical address to the entry for the target microcode program in the function table. Subsequently, the host can directly send an access request including the logical address to the DPU to access instructions in the target microcode program, such as to read or modify the instructions.

[0151] In summary, the embodiment of the present application provides a first static microcode program deployed in the firmware of the DPU, and the first static microcode program is used to dynamically offload any microcode program of the host to the DPU. The association relationship between the first static microcode program and the first indication information is expanded. Accordingly, the host is configured with a corresponding first user-oriented interface, and the user can trigger the unloading of the microcode program through the first interface. Based on this, the host can dynamically offload the microcode program to the DPU during the operation of the DPU by simply carrying the first indication information and the microcode program to be unloaded in the message.

[0152] After the target microcode program is offloaded to the DPU based on the embodiment shown in FIG6 , a subsequent user can call the target microcode program on the DPU. In some embodiments, a corresponding target indication information (also known as a message type) can be configured for the target microcode program, and the correspondence between the logical address of the target microcode program and the target indication information is stored in the DPU's microcode table, so that the host can subsequently directly call the target microcode program by carrying the target indication information in the message.

[0153] Optionally, in other embodiments, in order to avoid the limited number of microcode programs that can be unloaded on the DPU due to the space limitation of the DPU register, the embodiment of the present application also provides a second static microcode program deployed in the firmware of the DPU, and the second static microcode program is used to call any microcode program on the DPU. And the association relationship between the second static microcode program and the second indication information is extended in the microcode table. Accordingly, the host is configured with a corresponding user-oriented second interface, and the user can trigger the call of the microcode program through the second interface. Based on this, the host only needs to carry the second indication information and the relevant information of the microcode program to be called in the message to call any microcode program on the DPU, without the need to store the correspondence between each microcode program and the indication information in the microcode table of the DPU register. The implementation method is described in detail below.

[0154] Figure 11 is a schematic diagram of another process of calling a microcode program according to an embodiment of the present application. As shown in Figure 11, the process includes the following steps.

[0155] Step 1101: The host obtains a call request triggered by a user through a second interface. The call request carries a user identifier of a target microcode program and parameters required for executing the target microcode program.

[0156] FIG12 is a schematic diagram of a second interface provided by an embodiment of the present application. As shown in FIG12 , when the host detects a user clicking on the "Second Interface" option on the display interface, a user identification input window and a parameter input window are displayed, allowing the user to trigger a call request for the target microcode program based on these two windows.

[0157] Step 1102: The host determines a logical address allocated to the target microcode program based on the user identifier of the target microcode program.

[0158] The implementation of step 1102 may refer to the implementation of step 602 in the embodiment of FIG6 , and will not be described in detail here.

[0159] Step 1103: The host sends a second message to the DPU, where the second message carries second indication information, parameters, and a logical address.

[0160] Figure 13 is a schematic diagram of the format of a second message provided in an embodiment of the present application. As shown in Figure 13, the sub-type field of the message sent by the host to the DPU carries the second indication information, and the data field carries parameters (parameter_0) and a logical address (gpa_1).

[0161] Through the values ​​of the module type (module_type) and subtype (sub-type) fields, the DPU can determine that the host currently needs to execute the second static microcode program, that is, it needs to call a microcode program on the DPU.

[0162] Optionally, in other embodiments, to facilitate subsequent DPU operations, the second message may further carry a function identifier registered for the target microcode program, wherein the host may search the function identifier registered for the target microcode program from the function table based on the user identifier.

[0163] Step 1104: The DPU receives a second message from the host.

[0164] Step 1105: In response to the second indication information, the DPU executes a second static microcode program, where the second static microcode program is used to obtain microcode data based on a logical address and determine an execution result based on the microcode data and parameters.

[0165] In response to the second indication information, the DPU executes the second static microcode program, which can be understood as: based on the second indication information, the DPU searches the microcode table for the static microcode program corresponding to the second indication information to obtain the second static microcode program.

[0166] In other words, the DPU stores the association between the second indication information and the second static microcode program. By pre-storing the association between the second indication information and the second static microcode program, the DPU can quickly determine whether the second static microcode program needs to be executed upon receiving a message including the second indication information, thereby improving the DPU's execution efficiency.

[0167] The DPU may execute the second static microcode program by, for example, waking up an idle microcode thread and passing information related to the second static microcode program, such as the logical address of the second static microcode program, to the microcode thread. The microcode thread then reads instructions from the second static microcode program based on the logical address of the second static microcode program and executes the instructions to execute the second static microcode program.

[0168] When executing the second static microcode program, the microcode thread can generate a function pointer based on the function identifier and the logical address, obtain microcode data corresponding to the target microcode program based on the function pointer, and then determine the execution result based on the microcode data and parameters.

[0169] Step 1106: The DPU returns the execution result to the host.

[0170] Step 1107: The host receives the execution result returned by the DPU.

[0171] The following uses the interaction between the local host and the DPU in FIG1 as an example to illustrate how the host unloads the target microcode program to the DPU and calls the target microcode program.

[0172] FIG14 is a flow chart of a process of uninstalling a microcode program and calling a microcode program provided by an embodiment of the present application. As shown in FIG14 , the real-time microcode program uninstallation process on the host side is shown by the black solid line with an arrow in FIG14 . Specifically, it includes the following steps.

[0173] Step (1): Users and developers can design and implement DPU applications according to the RPC model, including an RPC client program running on the host and an RPC server program running on the DPU. The RPC server program is the target microcode program to be offloaded. Among them, DPU applications can be storage applications, network applications, security applications, or virtualization applications.

[0174] Step (2): The target microcode program is first compiled and linked by a cross-compiler on the host into microcode data that can be executed by the microcode thread.

[0175] Step (3): The runtime RPC controller on the host will assign a logical address to the target microcode program based on the function table maintained in the host memory, and register the function identifier for the target microcode program on the DPU by sending a third message to the DPU. The runtime RPC controller records the meta-information about the target microcode program, which includes the function identifier, logical address, and user identifier.

[0176] Step (4): During runtime, the RPC controller sends the logical address and microcode data in the first message to the DPU through the driver, and the message is captured by the hardware scheduler in the DPU.

[0177] Step (5): The hardware scheduler determines, based on the reserved field (i.e., the first indication information) in the first message, that the first static microcode program (i.e., function_offload) should be executed and wakes up an idle microcode thread to execute the first static microcode program. During the execution of the first static microcode program, the microcode thread sequentially packages the instructions in the received microcode data and calls the application programming interface (API) of the smart memory according to the logical address and address translation rules to save the received instructions.

[0178] As shown in FIG14 , the process of calling the microcode program in real time on the host side is shown by the black dotted line with an arrow in FIG14 , which specifically includes the following steps.

[0179] Step (1): The RPC client program on the host sends a call request to the runtime RPC controller according to a predefined function interface (ie, the second interface).

[0180] Step (2): The RPC controller queries the function table and obtains the logical address of the RPC server program (i.e., the target microcode program) corresponding to the RPC client program on the DPU, and packages the logical address, function identifier, parameters provided by the client, etc. together in a second message and sends it to the DPU, which is captured by the hardware scheduler in the DPU.

[0181] Step (3): The hardware scheduler determines that the second static microcode program (i.e., function_exec) should be executed based on the reserved field (i.e., the second indication information) in the second message and wakes up an idle microcode thread to execute the second static microcode program. At the same time, the logical address, function identifier, and parameters are also passed to the microcode thread. The second static microcode program creates a function pointer using the function identifier and logical address, passes in the parameters for execution, and finally returns the execution result to the RPC client program.

[0182] In addition, the RPC framework shown in Figure 14 is also compatible with calling DPU microcode based on the "firmware update" mode. The specific process is shown by the black dotted line with an arrow in Figure 14. As shown in Figure 14, for a data packet from the network (such as a remote host), the hardware scheduler in the DPU disassembles and analyzes the message type (i.e., indication information) of the data packet, queries the microcode table based on the indication information to directly obtain the logical address of the microcode program to be called, and then wakes up the idle microcode thread to execute the microcode thread.

[0183] In summary, the embodiment of the present application provides a microcode thread calling process that greatly increases the number of microcode programs that can be supported on the DPU, breaking through the bottleneck of DPU usage. At the same time, for the remote host, the call of the microcode thread on the DPU can be realized through unilateral RDMA, which improves the performance by 3-6 times. Figure 15 is a performance comparison diagram provided by an embodiment of the present application. Solution 1 in Figure 15 is: the microcode program is burned into the DPU in the form of firmware when the computer is turned on. Solution 2 is the microcode thread unloading and calling solution shown in Figure 14. As shown in Figure 15, compared with Solution 1, Solution 2 has a significant improvement in throughput (unit: number of queries per second (OPS / s)) when writing data to the DPU (that is, unloading the microcode program). In addition, Solution 2 in Figure 15 reads data from the DPU, which means that the host calls the microcode program in the DPU.

[0184] Furthermore, as DPU usage scenarios expand, more and more microcode programs are being offloaded to the DPU, and even different microcode programs need to use the DPU for computing simultaneously. When different microcode programs use the same DPU simultaneously, it is necessary to ensure that resources are used efficiently while also ensuring security.

[0185] In some scenarios, due to limited resources such as DPU memory, it may not be possible to load all registered microcode programs. In addition, different microcode programs require different amounts of memory space. To ensure the efficiency of remote microcode calls, a microcode management strategy that can achieve load balancing is necessary.

[0186] In some embodiments of the present application, before the host calls the target microcode program on the DPU, the host will first check the existence flag of the target microcode program in the function table. If the existence flag is 1 (i.e., it has been loaded), the target microcode program will be called directly; otherwise, the target microcode program will be unloaded to the DPU and the existence flag will be set to 1. In this process, if the memory of the DPU is insufficient, for example, there are not enough logical addresses currently allocated to the target microcode program, the least recently used (LRU) strategy will be used to evict a microcode program in the function table, that is, to delete the microcode program from the DPU and delete the table entry corresponding to the microcode program in the function table. The LRU strategy can ensure that the function table will not be occupied by microcode programs that are used for a short time, resulting in a denial-of-service (DoS) attack.

[0187] Furthermore, to avoid memory fragmentation, the host can use a buddy allocator to manage the logical addresses of the DPU's memory, ensuring memory reuse when microcode programs are unloaded or deleted (i.e., swapped in or out). Furthermore, to ensure load balancing, the DPU's hardware scheduler can use time-sharing multiplexing and prioritize low-frequency programs, ensuring that the unloading or invocation of different microcode programs can be fairly distributed across the DPU's hardware.

[0188] The above load balancing strategy can increase DPU throughput by about 3.57 times, while reducing latency by about 40.9%-59.5%.

[0189] In other scenarios, it's also necessary to authenticate user-initiated remote microcode program calls to prevent erroneous calls and malicious attacks. Furthermore, microcode program calls must ensure that different microcode programs don't access the data of other microcode programs, thereby violating isolation. Therefore, a microcode management strategy that ensures security is also required.

[0190] In an embodiment of the present application, as shown in Figure 16, when the host registers the target microcode program, it can first randomly generate a random number as the owner key (okey) of the microcode program, and then provide the key and the signed target microcode program together to the runtime RPC controller of the host. At the same time, the key is transmitted to the client program through a secure communication channel. And after obtaining the secret key, the host can also add the secret key to the function table to obtain an extended function table. Figure 17 is a schematic diagram of an extended function table provided in an embodiment of the present application. As shown in Figure 17, the extended function table includes information such as function identification, user identification, logical address, secret key, priority, and existence flag for the target microcode program.

[0191] As shown in Figure 16, when calling the target microcode program, the client program attaches an "okey" and its request content. The request content may be the parameters required to execute the target microcode program. The runtime RPC controller verifies the permissions (okey = okey') when querying the function table before calling the target microcode program on the DPU. Since only the registrant possesses the correct key, only the registrant and the remote caller with the shared key can call the target microcode program. Therefore, this method can implement a secure permissions management mechanism.

[0192] In addition, in the implementation of this application, in order to prevent exhaustive attacks, when the runtime RPC controller queries the function table to verify permissions, when the number of verification errors exceeds the threshold T, the target microcode program will be deregistered (that is, deleted from the DPU), removed from the function table, and an error warning message will be thrown.

[0193] In addition, to ensure the isolation of the microcode program itself (one microcode program will not call the data of another program), as shown in Figure 16, the host can use a trusted third party (such as the developer of this firmware) to calculate the hash of the target microcode program using a hash tool such as the secure hash algorithm (SHA) 256 and sign it. At the same time, the public key of the signature is stored in the DPU. When the target microcode program is uninstalled, the first static microcode program on the DPU will calculate the hash value of the target microcode program based on the public key and verify the correctness of the signature, thereby ensuring that the uninstalled target microcode program has been verified by the trusted third party.

[0194] Figure 18 is a schematic diagram of the structure of a device for uninstalling a microcode program provided in an embodiment of the present application. The device is applied to a DPU whose firmware includes a first static microcode program. As shown in Figure 18, the device 1800 includes the following modules.

[0195] The first receiving module 1801 is used to receive a first message from the host, the first message carries first indication information, microcode data and the logical address of the microcode data in the DPU, the microcode data is the data after compiling the program body of the target microcode program to be uninstalled; the specific implementation method can refer to step 604 in the embodiment of Figure 6.

[0196] The first execution module 1802 is used to execute the first static microcode program in response to the first indication information. The first static microcode program is used to convert the logical address into a physical address and unload the microcode data to the storage location corresponding to the physical address. The specific implementation method can refer to step 605 in the embodiment of Figure 6.

[0197] Optionally, the DPU stores an association relationship between the first indication information and the first static microcode program.

[0198] Optionally, the DPU stores an address conversion rule, where the address conversion rule is used to indicate a mapping relationship between a logical address and a physical address;

[0199] The first static microcode program is used to convert the logical address into a physical address based on an address conversion rule.

[0200] Optionally, the first receiving module is configured to:

[0201] A first message is received from a host computer via a serial computer bus or a network port.

[0202] Optionally, the firmware of the DPU includes a second static microcode program;

[0203] The device also includes:

[0204] A second receiving module is used to receive a second message from the host, where the second message carries second instruction information, parameters required for executing the target microcode program, and a logical address;

[0205] a second execution module, configured to execute a second static microcode program in response to the second indication information, the second static microcode program being configured to obtain microcode data based on a logical address and determine an execution result based on the microcode data and parameters;

[0206] The first sending module is used to return the execution result to the host.

[0207] Optionally, the DPU stores an association relationship between the second indication information and the second static microcode program.

[0208] Optionally, the firmware of the DPU includes a third static microcode program;

[0209] The device also includes:

[0210] a third receiving module, configured to receive a third message from the host, the third message carrying third indication information and a user identifier of the target microcode program;

[0211] A third execution module is configured to execute a third static microcode program in response to the third indication information, wherein the third static microcode program is configured to register a function identifier based on a user identifier of the target microcode program;

[0212] The second sending module is used to return the function identifier to the host;

[0213] The second message also carries a function identifier, and the second static microcode program is used to generate a function pointer based on the function identifier and the logical address, and obtain microcode data based on the function pointer.

[0214] Optionally, the DPU stores an association relationship between the third indication information and the third static microcode program.

[0215] An embodiment of the present application provides a first static microcode program deployed in the firmware of the DPU. The first static microcode program is used to dynamically offload any microcode program of the host to the DPU. The association relationship between the first static microcode program and the first indication information is expanded. Accordingly, the host is configured with a corresponding first user-oriented interface, through which the user can trigger the offloading of the microcode program. Based on this, the host can dynamically offload the microcode program to the DPU during the operation of the DPU by simply carrying the first indication information and the microcode program to be offloaded in the message.

[0216] It should be noted that the apparatus for uninstalling a microcode program provided in the above embodiment is only exemplified by the division of the above functional modules when uninstalling a microcode program. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus for uninstalling a microcode program provided in the above embodiment and the method embodiment for uninstalling a microcode program are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0217] FIG19 is a schematic diagram of the structure of another device for unloading microcode programs provided in an embodiment of the present application. The device is applied to a host computer, which is connected to a data processing chip DPU. The host computer includes a first interface. The device 1900 includes:

[0218] The first acquisition module 1901 is used to obtain an uninstall request triggered by the user through the first interface. The uninstall request carries the user identifier of the target microcode program and the program body of the target microcode program. For specific implementation, please refer to step 601 in the embodiment of Figure 6.

[0219] The second acquisition module 1902 is configured to acquire the logical address allocated to the target microcode program based on the user identifier of the target microcode program. For a specific implementation, reference may be made to step 602 in the embodiment of FIG. 6 .

[0220] The first sending module 1903 is configured to send a first message to the DPU. The first message carries first indication information, microcode data, and a logical address. The microcode data is data compiled from the target microcode program body. The first indication information instructs the DPU to execute a first static microcode program, which converts the logical address into a physical address and unloads the microcode data to a storage location corresponding to the physical address. For a specific implementation, see step 603 in the embodiment of FIG. 6 .

[0221] Optionally, the host further includes a second interface; the device further includes:

[0222] A third acquisition module is used to acquire a call request triggered by the user through the second interface, where the call request carries a user identifier of the target microcode program and parameters required for executing the target microcode program;

[0223] a determination module, configured to determine a logical address allocated to a target microcode program based on a user identifier of the target microcode program;

[0224] a second sending module, configured to send a second message to the DPU, the second message carrying second indication information, parameters, and a logical address, the second indication information being used to instruct the DPU to execute a second static microcode program, the second static microcode program being used to obtain microcode data based on the logical address and determine an execution result based on the microcode data and the parameters;

[0225] The first receiving module is used to receive the execution result returned by the DPU.

[0226] Optionally, the host further includes a third interface; the device further includes:

[0227] a fourth acquisition module, configured to acquire a registration request triggered by a user through the third interface, the registration request carrying a user identifier of a target microcode program and a size of the target microcode program;

[0228] The allocation module is used to allocate a logical address to the target microcode program based on the size of the target microcode program and to establish an association relationship between the user identifier of the target microcode program and the logical address.

[0229] Optionally, the device further comprises:

[0230] a third sending module, configured to send a third message to the DPU, the third message carrying third indication information and a user identifier of the target microcode program, the third indication information being used to instruct the DPU to execute a third static microcode program, the third static microcode program being used to register a function identifier based on the user identifier of the target microcode program;

[0231] The second receiving module is used to receive the function identifier returned by the DPU;

[0232] The second message carries a function identifier.

[0233] An embodiment of the present application provides a first static microcode program deployed in the firmware of the DPU. The first static microcode program is used to dynamically offload any microcode program of the host to the DPU. The association relationship between the first static microcode program and the first indication information is expanded. Accordingly, the host is configured with a corresponding first user-oriented interface, through which the user can trigger the offloading of the microcode program. Based on this, the host can dynamically offload the microcode program to the DPU during the operation of the DPU by simply carrying the first indication information and the microcode program to be offloaded in the message.

[0234] It should be noted that the apparatus for uninstalling a microcode program provided in the above embodiment is only exemplified by the division of the above functional modules when uninstalling a microcode program. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus for uninstalling a microcode program provided in the above embodiment and the method embodiment for uninstalling a microcode program are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0235] Figure 20 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. The host in the aforementioned embodiment can be implemented by the computer device shown in Figure 20. Referring to Figure 20, the computer device includes at least one processor 2001, a communication bus 2002, a memory 2003, and at least one communication interface 2004.

[0236] The processor 2001 may be a general-purpose central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application.

[0237] The communication bus 2002 may include a pathway for transmitting information between the aforementioned components.

[0238] The memory 2003 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 2003 may exist independently and be connected to the processor 2001 via the communication bus 2002. The memory 2003 may also be integrated with the processor 2001.

[0239] Memory 2003 is used to store program code for executing the solution of the present application, and is controlled by processor 2001 for execution. Processor 2001 is used to execute the program code stored in memory 2003. The program code may include one or more software modules. The host in the aforementioned embodiment can determine data for developing an application through processor 2001 and one or more software modules in the program code in memory 2003.

[0240] The communication interface 2004 uses any transceiver or other device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), etc.

[0241] In a specific implementation, as an embodiment, a computer device may include multiple processors, such as processor 2001 and processor 2005 shown in Figure 20. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. The processor here may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0242] In a specific implementation, as an embodiment, the computer device may further include an output device 2006 and an input device 2007. The output device 2006 communicates with the processor 2001 and can display information in a variety of ways. For example, the output device 2006 can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 2007 communicates with the processor 2001 and can receive user input in a variety of ways. For example, the input device 2007 can be a mouse, a keyboard, a touch screen device, or a sensor device.

[0243] The aforementioned computer device may be a general-purpose computer device or a dedicated computer device. In a specific implementation, the computer device may be a desktop computer, a portable computer, a network server, a personal digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. The embodiments of the present application do not limit the type of computer device.

[0244] In addition, as shown in Figure 21, an embodiment of the present application further provides a DPU 2100. DPU 2100 includes a processor 2101 and a memory 2102. The memory 2102 is used to store programs that support the DPU in executing the methods provided in the embodiments of the present application, as well as data involved in implementing the methods provided in the embodiments of the present application. Processor 2101 is configured to execute the programs stored in the memory. For example, the processor includes the multiple processing cores shown in Figure 2, and the memory includes the SMF shown in Figure 2.

[0245] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a digital versatile disc (DVD)), or a semiconductor medium (eg, a solid state disk (SSD)).

[0246] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0247] The above content is not intended to limit the embodiments of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the scope of protection of the embodiments of the present application.

Claims

1. A method for uninstalling a microcode program, characterized in that: The method is applied to a data processing chip DPU, wherein the firmware of the DPU includes a first static microcode program; the method includes: The DPU receives a first message from a host, the first message carrying first indication information, microcode data, and a logical address of the microcode data in the DPU, the microcode data being data compiled from a program body of a target microcode program to be uninstalled; In response to the first indication information, the DPU executes the first static microcode program, where the first static microcode program is used to convert the logical address into a physical address and unload the microcode data to a storage location corresponding to the physical address.

2. The method according to claim 1, characterized in that The DPU stores an association relationship between the first indication information and the first static microcode program.

3. The method according to claim 1 or 2, characterized in that The DPU stores an address conversion rule, where the address conversion rule is used to indicate a mapping relationship between a logical address and a physical address; The first static microcode program is used to convert the logical address into the physical address based on the address conversion rule.

4. The method according to any one of claims 1 to 3, characterized in that: The DPU receives a first message from a host, including: The DPU receives a first message from the host via a serial computer bus or a network port.

5. The method according to any one of claims 1 to 4, characterized in that: The firmware of the DPU includes a second static microcode program; After the DPU executes the first static microcode program, the method further includes: The DPU receives a second message from the host, where the second message carries second indication information, parameters required to execute the target microcode program, and the logical address; In response to the second indication information, the DPU executes the second static microcode program, where the second static microcode program is used to obtain the microcode data based on the logical address and determine an execution result based on the microcode data and the parameter; The DPU returns the execution result to the host.

6. The method according to claim 5, characterized in that The DPU stores an association relationship between the second indication information and the second static microcode program.

7. The method according to claim 5 or 6, characterized in that The firmware of the DPU includes a third static microcode program; The method further comprises: The DPU receives a third message from the host, where the third message carries third indication information and a user identifier of the target microcode program; In response to the third indication information, the DPU executes the third static microcode program, wherein the third static microcode program is used to register a function identifier based on a user identifier of the target microcode program; The DPU returns the function identifier to the host; The second message also carries the function identifier, and the second static microcode program is used to generate a function pointer based on the function identifier and the logical address, and obtain the microcode data based on the function pointer.

8. The method according to claim 7, characterized in that The DPU stores an association relationship between the third indication information and the third static microcode program.

9. A method for uninstalling a microcode program, characterized in that: The method is applied to a host, the host is connected to a data processing chip DPU, and the host includes a first interface; the method includes: The host obtains an uninstall request triggered by a user through the first interface, wherein the uninstall request carries a user identifier of a target microcode program and a program body of the target microcode program; The host obtains a logical address allocated to the target microcode program based on a user identifier of the target microcode program; The host sends a first message to the DPU, the first message carrying first indication information, microcode data and the logical address, the microcode data being data after compiling the program body of the target microcode program; The first indication information is used to instruct the DPU to execute a first static microcode program, and the first static microcode program is used to convert the logical address into a physical address and unload the microcode data to a storage location corresponding to the physical address.

10. The method according to claim 9, characterized in that The host also includes a second interface; the method also includes: The host obtains a call request triggered by a user through the second interface, where the call request carries a user identifier of the target microcode program and parameters required for executing the target microcode program; The host determines a logical address allocated to the target microcode program based on a user identifier of the target microcode program; The host sends a second message to the DPU, the second message carrying second indication information, the parameter and the logical address, the second indication information is used to instruct the DPU to execute a second static microcode program, the second static microcode program is used to obtain the microcode data based on the logical address, and determine an execution result based on the microcode data and the parameter; The host receives the execution result returned by the DPU.

11. The method according to claim 10, characterized in that The host further includes a third interface; the method further includes: The host obtains a registration request triggered by a user through the third interface, where the registration request carries a user identifier of the target microcode program and a size of the target microcode program; The host allocates the logical address to the target microcode program based on the size of the target microcode program, and establishes an association relationship between the user identifier of the target microcode program and the logical address.

12. The method according to claim 11, characterized in that The method further comprises: The host sends a third message to the DPU, the third message carrying third indication information and a user identifier of the target microcode program, the third indication information is used to instruct the DPU to execute a third static microcode program, and the third static microcode program is used to register a function identifier based on the user identifier of the target microcode program; The host receives the function identifier returned by the DPU; The second message carries the function identifier.

13. A device for uninstalling a microcode program, characterized in that: The device is applied to a data processing chip DPU, and the firmware of the DPU includes a first static microcode program; the device includes: A first receiving module, configured to receive a first message from a host, wherein the first message carries first indication information, microcode data, and a logical address of the microcode data in the DPU, wherein the microcode data is data obtained by compiling a program body of a target microcode program to be uninstalled; The first execution module is used to execute the first static microcode program in response to the first indication information, wherein the first static microcode program is used to convert the logical address into a physical address and unload the microcode data to a storage location corresponding to the physical address.

14. The device according to claim 13, characterized in that The DPU stores an association relationship between the first indication information and the first static microcode program.

15. The device according to claim 13 or 14, characterized in that The DPU stores an address conversion rule, where the address conversion rule is used to indicate a mapping relationship between a logical address and a physical address; The first static microcode program is used to convert the logical address into the physical address based on the address conversion rule.

16. The device according to any one of claims 13 to 15, characterized in that: The first receiving module is used for: A first message is received from the host via a serial computer bus or a network port.

17. The device according to any one of claims 13 to 16, characterized in that: The firmware of the DPU includes a second static microcode program; The device also includes: The second receiving module is used to receive a second message from the host, wherein the second message carries a second instruction information and executes the target The parameters and the logic address required by the microcode program; a second execution module, configured to execute the second static microcode program in response to the second indication information, wherein the second static microcode program is configured to obtain the microcode data based on the logical address and determine an execution result based on the microcode data and the parameter; The first sending module is used to return the execution result to the host.

18. The device according to claim 17, characterized in that The DPU stores an association relationship between the second indication information and the second static microcode program.

19. The device according to claim 17 or 18, characterized in that The firmware of the DPU includes a third static microcode program; The device also includes: A third receiving module, used for receiving a third message from the host, wherein the third message carries third indication information and a user identifier of the target microcode program; A third execution module, configured to execute the third static microcode program in response to the third indication information, wherein the third static microcode program is used to register a function identifier based on a user identifier of the target microcode program; A second sending module, used for returning the function identifier to the host; The second message also carries the function identifier, and the second static microcode program is used to generate a function pointer based on the function identifier and the logical address, and obtain the microcode data based on the function pointer.

20. The device according to claim 19, characterized in that The DPU stores an association relationship between the third indication information and the third static microcode program.

21. A device for uninstalling a microcode program, characterized in that: The device is applied to a host, the host is connected to a data processing chip DPU, and the host includes a first interface; the device includes: A first acquisition module, configured to acquire an uninstallation request triggered by a user through the first interface, wherein the uninstallation request carries a user identifier of a target microcode program and a program body of the target microcode program; A second acquisition module, configured to acquire a logical address allocated to the target microcode program based on a user identifier of the target microcode program; A first sending module, configured to send a first message to the DPU, wherein the first message carries first indication information, microcode data, and the logical address, wherein the microcode data is data obtained by compiling a program body of the target microcode program; The first indication information is used to instruct the DPU to execute a first static microcode program, and the first static microcode program is used to convert the logical address into a physical address and unload the microcode data to a storage location corresponding to the physical address.

22. The device according to claim 21, characterized in that The host further includes a second interface; the device further includes: A third acquisition module, used to acquire a call request triggered by a user through the second interface, wherein the call request carries a user identifier of the target microcode program and parameters required for executing the target microcode program; A determination module, configured to determine a logical address allocated to the target microcode program based on a user identifier of the target microcode program; a second sending module, configured to send a second message to the DPU, the second message carrying second indication information, the parameter and the logical address, the second indication information being used to instruct the DPU to execute a second static microcode program, the second static microcode program being used to obtain the microcode data based on the logical address, and determine an execution result based on the microcode data and the parameter; The first receiving module is used to receive the execution result returned by the DPU.

23. The device according to claim 22, characterized in that The host further includes a third interface; the device further includes: a fourth acquisition module, configured to acquire a registration request triggered by a user through the third interface, wherein the registration request carries a user identifier of the target microcode program and a size of the target microcode program; The allocation module is used to allocate the logical address to the target microcode program based on the size of the target microcode program, and to establish an association relationship between the user identifier of the target microcode program and the logical address.

24. The device according to claim 23, characterized in that The device also includes: The third sending module is used to send a third message to the DPU, wherein the third message carries the third indication information and the target microcode program The third indication information is used to instruct the DPU to execute a third static microcode program, and the third static microcode program is used to register a function identifier based on the user identifier of the target microcode program; A second receiving module, used for receiving the function identifier returned by the DPU; The second message carries the function identifier.

25. A data processing chip DPU, characterized in that: The DPU includes a memory and a processor; The memory is used to store a program that supports the DPU to execute the method described in any one of claims 1 to 8, and to store data involved in implementing the method described in any one of claims 1 to 8; The processor is configured to execute the program stored in the memory.

26. A host, characterized in that: The host includes a memory and a processor; The memory is used to store a program that supports the host to execute the method described in any one of claims 9 to 12, and to store data involved in implementing the method described in any one of claims 9 to 12; The processor is configured to execute the program stored in the memory.

27. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the method described in any one of claims 1 to 8, or enable the computer to execute the method described in any one of claims 9 to 12.

Images