Method and device for uninstalling microcode program and related product

Abstract

The invention discloses a method and device for uninstalling a microcode program and a related product, and belongs to the technical field of computers. The embodiment of the invention provides a first static microcode program in firmware of a DPU (Data Processing Unit), wherein the first static microcode program is used for dynamically unloading any microcode program of a host to the DPU. And expanding an association relationship between the first static microcode program and the first indication information. Correspondingly, the host is provided with a corresponding user-oriented first interface, and a user can trigger unloading of the microcode program through the first interface. On the basis, the host can dynamically unload the microcode program to the DPU in the running process of the DPU only by carrying the first indication information and the microcode program to be unloaded in the message. Therefore, the microcode program can be dynamically unloaded from the DPU in the running process of the DPU, a certain microcode program can be dynamically modified in the running process of the DPU, and service interruption corresponding to other microcode programs is not needed.

Description

Technical Field

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

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

[0003] In the related art, when the DPU is powered on, all microcode programs to be unloaded to the DPU are compiled and packaged into firmware and burned into the DPU, so that the host can call the microcode program on the DPU later. If a microcode program needs to be modified, all microcode programs are recompiled and packaged into firmware after the microcode program is modified, and re-burned into the DPU when the DPU is powered on, resulting in a long service interruption time when the service is upgraded. Summary of the invention

[0004] The embodiment of the present application provides a method, device and computer storage medium for unloading a microcode program, which can realize dynamic unloading of the microcode program to the DPU during the operation of the DPU, thereby realizing dynamic modification of a microcode program during the operation of the DPU without interrupting the services corresponding to other microcode programs. The technical solution is as follows:

[0005] In a first aspect, a method for unloading a microcode program is provided, the method being applied to a data processing chip DPU, the firmware of the DPU comprising a first static microcode program; the method comprising: the DPU receiving 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 after compiling a program body of a target microcode program to be unloaded; in response to the first indication information, the DPU executing a first static microcode program, the first static microcode program being used to convert a logical address into a physical address, and unloading the microcode data to a storage location corresponding to the physical address.

[0006] 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 only 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 service interruption corresponding to other microcode programs.

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

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

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

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

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

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

[0013] Based on the method provided in the first aspect, in a possible implementation, the firmware of the DPU includes a second static microcode program; after the DPU executes the first static microcode program, the method also 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.

[0014] 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. Based on this, the host can call any microcode program on the DPU by carrying the second indication information and the relevant information of the microcode program to be called in the message, without the need to store the correspondence between each microcode program and the indication information in the microcode table of the DPU register.

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

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

[0017] Based on the method provided in the first aspect, in a 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.

[0018] The embodiment of the present application also provides a third static microcode program deployed in the firmware of the DPU, and the third static microcode program is used to register a microcode program on the host. And the association relationship between the third static microcode program and the third indication information is extended in the microcode table. Based on this, the host can register a microcode program on the DPU by carrying the third indication information and the relevant information of the microcode program to be registered in the message.

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

[0020] 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 currently, thereby improving the execution efficiency of the DPU.

[0021] In a second aspect, a method for uninstalling a microcode program is provided, the method being applied to a host, the host being connected to a data processing chip DPU, the host comprising a first interface; the method comprising:

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

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

[0024] The host sends a first message to the DPU, the first message carrying first indication information, microcode data and a logical address, the microcode data being data after compiling a program body of a target microcode program;

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

[0026] 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 realize dynamic unloading of 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 extended 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 realize the dynamic unloading of the microcode program to the DPU during the operation of the DPU by carrying the first indication information and the microcode program to be unloaded in the message.

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

[0028] 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 only by 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.

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

[0030] In an embodiment of the present application, a user may first register a target microcode program to be uninstalled on a 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.

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

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

[0033] In a third 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 behavior of uninstalling a microcode program in the first aspect. The device for uninstalling a microcode program includes at least one module, and the at least one module is used to implement the method for uninstalling a microcode program provided in the first aspect.

[0034] 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 behavior of uninstalling a microcode program in the second aspect. The device for uninstalling a microcode program includes at least one module, and the at least one module is used to implement the method for uninstalling a microcode program provided in the second aspect.

[0035] In a fifth aspect, a DPU is provided, the DPU comprising a processor and a memory, the memory being used to store a program supporting the DPU to execute the method for unloading a microcode program provided in the first aspect, and storing data involved in 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.

[0036] In a sixth aspect, a host is provided, the host comprising a processor and a memory, the memory being used to store a program supporting the host to execute the method for unloading a microcode program provided in the second aspect, and storing data involved in 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.

[0037] In the seventh aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores instructions, which, when executed on a computer, enables the computer to execute the method for unloading a microcode program described in the first aspect, or enables the computer to execute the method for unloading a microcode program described in the second aspect.

[0038] 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 a microcode program described in the first aspect, or enables the computer to execute the method for unloading a microcode program described in the second aspect.

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

[0040] Figure 1 It is a schematic diagram of the architecture of a system for uninstalling a microcode program provided in an embodiment of the present application;

[0041] Figure 2This is a schematic diagram of the architecture of a DPU provided in an embodiment of the present application;

[0042] Figure 3 It is an address conversion rule between a pointer address and a physical address provided in an embodiment of the present application;

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

[0044] Figure 5 is a flow chart of another method for unloading a microcode program provided in an embodiment of the present application;

[0045] Figure 6 is a flow chart of another method for unloading a microcode program provided in an embodiment of the present application;

[0046] Figure 7 is a schematic diagram of an interface of a first interface provided in an embodiment of the present application;

[0047] Figure 8 is a schematic diagram of an interface of a third interface provided in an embodiment of the present application;

[0048] Fig. 9 This is a schematic diagram of the format of a third message provided in an embodiment of the present application;

[0049] Fig.10 This is a schematic diagram of the format of a first message provided in an embodiment of the present application;

[0050] Fig.11 It is another flowchart of calling a microcode program provided by an embodiment of the present application;

[0051] Fig.12 is a schematic diagram of an interface of a second interface provided in an embodiment of the present application;

[0052] Fig.13 is a schematic diagram of the format of a second message provided in an embodiment of the present application;

[0053] Fig.14 It is a flowchart of uninstalling a microcode program and calling a microcode program provided by an embodiment of the present application;

[0054] Fig.15 This is a performance comparison diagram provided by an embodiment of the present application;

[0055] Fig.16 It is a flowchart of a key design for a target microcode program provided by an embodiment of the present application;

[0056] Fig.17 is a schematic diagram of an extended function table provided in an embodiment of the present application;

[0057] Fig.18 It is a structural schematic diagram of a device for unloading a microcode program provided in an embodiment of the present application;

[0058] Fig.19 It is a structural schematic diagram of another device for unloading a microcode program provided in an embodiment of the present application;

[0059] Fig. 20 is a structural schematic diagram of a computer device provided in an embodiment of the present application;

[0060] Fig.21 It is a structural schematic diagram of a DPU provided in an embodiment of the present application. DETAILED DESCRIPTION

[0061] 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 in conjunction with the accompanying drawings.

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

[0063] In the CPU-centric data processing architecture, the CPU is responsible for processing all network messages and data requests, making the CPU gradually become the bottleneck of computer processing performance. After that, technologies such as data plane development kit (DPDK) and remote direct memory access (RDMA) were proposed one after another, and data processing bypassing the host CPU became an important trend. In the data processing architecture of "CPU+graphics processing unit (GPU)+DPU", the DPU takes advantage of the data processing center to offload and accelerate network, storage, security, and virtualization services on the critical path, releasing the CPU's computing power, so that the CPU can focus on resource management and task scheduling, greatly improving the resource utilization and processing efficiency in the data processing architecture. However, the addition of new processing units has brought huge challenges to the user mode and programming mode. How to design a new data processing architecture with strong scalability, user / developer friendliness, and high performance has become a problem that needs to be solved urgently.

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

[0065] For example, the developer implements the RPC server running on the DPU side and the RPC client running on the host side respectively. 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 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 mode requires that the RPC server must be running and listening before the RPC client sends any remote call request.

[0066] In the above technology, on the one hand, the interaction between the RPC client and the RPC server needs to be completed through bilateral operations, which causes latency problems. On the other hand, the communication capability of the RPC protocol is limited, resulting in a limited number of microcode programs that can be offloaded to the DPU.

[0067] 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, which can realize flexible data packet message 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 design on the DPU. After the development is completed, all microcode programs are compiled and packaged into firmware (firmware) and burned into the flash memory of the DPU. When the DPU is turned on, all microcode programs are loaded into the smart memory according to the mapping relationship between the logical address (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).

[0068] Each specific microcode program is bound to the message type in the message or request, and the message type keyword and the microcode program entry address are stored in a specific register of the DPU. When the DPU receives a message or request, it parses the message type in the received message or request through hardware and obtains the microcode program entry address. After waking up the microcode thread and passing the entry address and some other metadata to the microcode thread, control is transferred to the microcode thread. The microcode thread starts to obtain instructions in the microcode program from the entry address and executes them.

[0069] The above solution completely relies on hardware, which improves system performance while bringing problems in 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 microcode program is modified, and then re-burned into the DPU when the DPU is turned on, resulting in a long service interruption time during business upgrades, which can last up to 20 minutes to 1 hour in some scenarios.

[0070] Based on this, an embodiment of the present application provides a method for unloading a microcode program, which can dynamically unload the microcode program to 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.

[0071] The following is an explanation of the system, method and related products for uninstalling microcode programs provided in the embodiments of the present application.

[0072] Figure 1 Schematic diagram of the architecture of a system for uninstalling microcode programs provided in an embodiment of the present application. Figure 1 As shown, the system includes a local host 10 , a DPU 20 and a remote host 30 .

[0073] 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 the delay and bandwidth of local communication.

[0074] The remote host 30 is connected to the DPU 20 through a network port for communication. For example, the remote host 30 and the DPU 20 can communicate through the network port based on the RDMA protocol, so that the remote host 30 can remotely call the DPU 20 based on the unilateral RDMA, thereby improving application performance.

[0075] like Figure 1As shown, 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 (NP) on the DPU 20 processes the user data using a user defined function (UDF), the data can be directly returned to the remote host 30 accordingly.

[0076] In the embodiment of the present application, the local host 10 or the remote host 30 can dynamically unload the microcode program to the DPU 20 through the method provided in the embodiment of the present application during the operation of the DPU 20, and remotely call the microcode program in the DPU 20. Figure 1 As shown, the microcode program includes, by way of example, a key-value pair search (KV Lookup) application, a user-defined function (UDF) application, and a filter application. Based on this, Figure 1 The system shown may also be referred to as a dynamic offloads development kit (DODK) based system.

[0077] In the embodiment of the present application, the DPU 20 is a DPU based on a multi-core processor, and the DPU 20 completes the interaction with the host through a microcode table, which is also called a microcode function call table, and the microcode table is stored in a register of the DPU 20. The microcode table is used to record the indication information (also called the message type) corresponding to the static microcode program in the firmware of the DPU 20, and the host can notify the DPU 20 of the static microcode program currently to be executed through the indication information carried in the message.

[0078] In order to dynamically unload the microcode program into the DPU 20 during the operation of the DPU 20, the embodiment of the present application provides a first static microcode program deployed in the firmware of the DPU 20, and the first static microcode program is used to dynamically unload any microcode program of the host to the DPU 20. And the association relationship between the first static microcode program and the first indication information is extended 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 20 during the operation of the DPU 20 by carrying the first indication information and the microcode program to be unloaded in the message.

[0079] Furthermore, 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 only 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.

[0080] In addition, the embodiment of the present application further provides a third static microcode program deployed in the firmware of the DPU 20, and the third static microcode program is used to register a microcode program on the host. And the association relationship between the third static microcode program and the third indication information is extended in the microcode table. Accordingly, the host is configured with a corresponding third user-oriented interface, and the user can trigger the registration of the microcode program through the third interface. Based on this, the host can register a microcode program on the DPU 20 by carrying the third indication information and the relevant information of the microcode program to be registered in the message.

[0081] In addition, if Figure 1 As shown, the DPU 20 also includes a hardware scheduler (hardware ucode threadscheduler). The hardware scheduler is used to manage and maintain instructions and data on the DPU, and uses the operating logic in the DPU 20 to implement dynamic remote calls of microcode programs in a manner that does not damage the original hardware and microcode wake-up process of the DPU 20. Among them, instructions can be understood as specific operations required to be performed during calculations, such as addition or subtraction or multiplication or division, and data can be understood as data used during calculations.

[0082] 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 here.

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

[0084] The user triggers a registration request through the third interface, and the registration request carries the user ID of the target microcode program to be uninstalled (marked as func name) and the size of the target microcode program. After the host obtains the registration request, it allocates a logical address to 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 ID of the target microcode program to the local function table.

[0085] Among them, when the host allocates the logical address, it is guaranteed that the logical address of the static microcode program that has been burned into the firmware of the DPU will not be overwritten, so that the original static microcode program in the DPU can still be executed normally. For example, the host can maintain a base address, which can be understood as the end address of the logical address of the static microcode program that has been burned into the DPU. Based on this, the host can allocate addresses from the base address each time it allocates addresses for the target microcode program to be uninstalled, thereby ensuring that the allocated address will not overwrite the logical address of the static microcode program that has been burned into the DPU.

[0086] 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, and the third microcode program registers a unique function identifier for the target microcode program.

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

[0088] The user triggers an uninstall request through the first interface, and 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 programs the program body of the target microcode program into instructions executable by the microcode thread through the cross compiler. For the convenience of subsequent understanding, the compiled instructions are referred to as microcode data. The host sends a first message to the DPU, and the first message carries the first indication information, the microcode data, and the logical address, so that the host executes the first static microcode program based on the first indication information.

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

[0090] The user triggers a call request through the second interface, and the call request carries the user identifier of the target microcode program and the parameters (marked as func_code) required to execute the target microcode program. 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 (marked as func_lva), and sends a second message to the DPU, the second message carries the second indication information, the logical address and the function identifier and the parameters, so that the host executes the second static microcode program based on the second indication information.

[0091] Figure 2 Schematic diagram of a DPU architecture provided by an embodiment of the present application. Figure 2 As shown, the DPU includes multiple processing cores, multiple SMFs, and two-level caches (L2 cache). The multiple processing cores, two-level caches, and multiple SMFs communicate with each other through a ring bus. Figure 2 Four SMFs are used as an example for illustration, and the embodiment of the present application does not limit the number of SMFs.

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

[0093] Based on the above content, it can be known 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.

[0094] 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 from 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 a 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, the microcode thread will execute a common microcode, which converts the instruction address stored in SPRAM into a function pointer and directly jumps to execute. The conversion of the instruction's logical address to the physical address is automatically completed by the first-level cache or the second-level cache when a miss event occurs. Figure 2 As shown, the hardware scheduler checks the first-level cache, the second-level cache and the SMF in sequence to obtain the required instructions.

[0095] In addition, in the embodiment of the present application, in order to realize the dynamic unloading of the microcode program during the operation of the DPU, the 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 turned on, so as to establish the mapping rules between the logical addresses and the 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, so that the target microcode program can be unloaded based on the physical address.

[0096] In addition, in the architecture of data-finger separation storage, 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, and the instructions in the target microcode program need to determine the location of the SMF to be stored according to the address conversion rule. Based on this, the address conversion rule can be understood as the mapping relationship between the logical address and the physical address of the SMF.

[0097] 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 a linear table descriptor in the SMF. Figure 3It is an address conversion rule between a logical address and a 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 by a combination of mem_index_hi, mem_index_lo, smf_id and offset. Mem_index_hi and mem_index_lo represent the index number of the linear table in SMF, smf_id represents the unique identifier of SMF, and offset represents the offset within 16 bytes in the SMF linear table.

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

[0099] In addition, considering the limited resources in the DPU, 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 DPU to access data or instructions stored in SMF through parameters such as mem_index_hi and mem_index_lo:

[0100] 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).

[0101] Through the above interface, technicians can store executable instructions in the specified physical location of the SMF of the DPU in advance, and Figure 3 The address conversion rules shown in the figure obtain its logical address, and subsequent technicians can use the logical address to trigger dynamic modification of the instructions in the SMF.

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

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

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

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

[0106] Step 403: The host sends a first message to the DPU, and the first message carries first indication information, microcode data and a logical address, and the microcode data is data after compiling the program body of the target microcode program; wherein 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 the physical address of the DPU, and unload the microcode data to the storage location corresponding to the physical address.

[0107] 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 extended. 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 carrying the first indication information and the microcode program to be unloaded in the message.

[0108] Figure 5 is a flowchart of another method for uninstalling a microcode program provided in an embodiment of the present application. The method is exemplarily applied to Figure 1 The DPU side of the system shown. Figure 5 As shown, the method includes the following steps.

[0109] Step 501: The DPU receives a first message from the 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.

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

[0111] 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 20 by only carrying the first indication information and the microcode program to be unloaded in the message.

[0112] Figure 6 is a flowchart of another method for uninstalling a microcode program provided in an embodiment of the present application. The method is exemplarily applied to Figure 1 In the system shown. Figure 6 As shown, the method includes the following steps.

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

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

[0115] Figure 7 is a schematic diagram of a first interface provided in an embodiment of the present application. Figure 7 As shown, when the host detects a user click operation 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.

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

[0117] When the host obtains an uninstall request for the target microcode program, in order to facilitate the subsequent DPU to uninstall 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, the host needs to first obtain the logical address allocated to the target microcode program. 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 the logical address is visible to the host, the logical address is also called the logical address on the host side.

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

[0119] 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, so as to improve the efficiency of subsequent uninstallation of the target microcode program.

[0120] By way of example, the implementation method for a user to register a target microcode program on a host may be: the host obtains a registration request triggered by the user through a third interface, the registration request carrying a user identifier of the target microcode program and a 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.

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

[0122] Figure 8 is a schematic diagram of a third interface provided in an embodiment of the present application. Figure 8 As shown, when the host detects a user click operation on the "third interface" option on the display interface, a user identification input window and a program size input window are displayed so that the user can trigger a registration request for the target microcode program based on these two windows.

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

[0124] In addition, considering that the user ID of the target microcode program is usually a string, which is not conducive to subsequent operations, the host can also register a function ID for the target program on the DPU, and the function ID can be a two-digit number. The function ID can be used to uniquely identify the target microcode program during subsequent internal interaction between the host and the DPU to improve the interaction efficiency between the two.

[0125] In some embodiments, the host may register a function identifier for a target program on a 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, 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.

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

[0127] Fig. 9 : is a schematic diagram of the format of a third message provided in an embodiment of the present application. Fig. 9 As shown, 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.

[0128] Fig. 9 Each line marked with DW is the header of the third message, where DW is the abbreviation of double word, which is used to indicate that each line has 4 bytes, a total of 32 bits. Each line marked with DATA is the data part of the third message except the header.

[0129] in addition, Fig. 9 The module type (module_type) value of the third message in the is used to indicate that the current message is sent by the host to the DPU. Through the value of the module type (module_type) and the value of the sub-type (sub-type) field, 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. In addition, Fig. 9 For the explanation of other fields in the message shown, please refer to the relevant standards and will not be explained one by one here.

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

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

[0132] That is, the DPU stores the association relationship between the third indication information and the third static microcode program. By pre-storing the association relationship 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.

[0133] The DPU may execute the third static microcode program by, for example, waking up an idle microcode thread and passing relevant information of the third static microcode program, such as the logical address of the third static microcode program, to the microcode thread. The microcode thread reads instructions in 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.

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

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

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

[0137] Through the value of the module type (module_type) and the value of the sub-type (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.

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

[0139] based on Figure 1 As can be seen from the illustrated architecture, the DPU can receive the first message from the host through a serial computer bus or a network port. In other words, the method provided in the embodiment of the present application is not only applicable to the local host but also to the remote host, which improves the application flexibility of the embodiment of the present application.

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

[0141] In response to the first indication information, the DPU executing the first static microcode program 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.

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

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

[0144] The DPU may execute the first static microcode program by, for example, waking up an idle microcode thread and passing the relevant information of the first static microcode program, such as the logical address of the first static microcode program, to the microcode thread. The microcode thread reads the instructions in 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.

[0145] In addition, based on the foregoing content, it can be known that the DPU in the embodiment of the present application adopts a storage structure with separated numbers and fingers, so 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 exemplarily as follows: 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 the data in the microcode data based on the correspondence when calling the target microcode program.

[0146] In some embodiments, the DPU stores an address conversion rule, which 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 a physical address based on the address conversion rule. By storing the address conversion rule locally, the execution efficiency of the first static microcode program can be improved.

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

[0148] Optionally, after converting the logical address to the physical address of the DPU, the DPU may also return the physical address to the host, and the host may add the physical address to the entry in the function table where the target microcode program is located. Subsequently, the host may directly send an access request including the logical address to the DPU to access the instructions in the target microcode program, such as reading or modifying the instructions.

[0149] 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 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 extended. 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 carrying the first indication information and the microcode program to be unloaded in the message.

[0150] based on Figure 6 After the target microcode program is unloaded to the DPU in the illustrated embodiment, the subsequent user can call the target microcode program on the DPU. In some embodiments, a corresponding target indication information (also called 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 microcode table of the DPU, so that the subsequent host can directly call the target microcode program by carrying the target indication information in the message.

[0151] 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. Correspondingly, 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 any microcode program on the DPU by carrying the second indication information and the relevant information of the microcode program to be called in the message, 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.

[0152] Fig.11 FIG. 1 is another flow chart of calling a microcode program provided by an embodiment of the present application. Fig.11 As shown, the process includes the following steps.

[0153] Step 1101: the host obtains a call request triggered by a user through a second interface, where the call request carries a user identifier of a target microcode program and parameters required to execute the target microcode program.

[0154] Fig.12 is a schematic diagram of an interface of a second interface provided in an embodiment of the present application. Fig.12As shown, when the host detects a user click operation on the "second interface" option on the display interface, a user identification input window and a parameter input window are displayed so that the user can trigger a call request for the target microcode program based on these two windows.

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

[0156] The implementation of step 1102 can refer to Figure 6 The implementation method of step 602 in the embodiment will not be described in detail here.

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

[0158] Fig.13 : is a schematic diagram of the format of a second message provided in an embodiment of the present application. Fig.13 As shown, 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 logical address (gpa_1), etc.

[0159] Through the value of the module type (module_type) and the value of the sub-type (sub-type) field, 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.

[0160] Optionally, in some other embodiments, in order to facilitate subsequent DPU operations, the second message may also 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.

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

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

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

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

[0165] The DPU may execute the second static microcode program by, for example, waking up an idle microcode thread and passing relevant information of the second static microcode program, such as the logical address of the second static microcode program, to the microcode thread. The microcode thread reads instructions in 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.

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

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

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

[0169] Below Figure 1 Taking the interaction between the local host and DPU in as an example, an example is given to illustrate how the host unloads the target microcode program to the DPU and calls the target microcode program.

[0170] Fig.14 FIG. 1 is a flow chart of uninstalling a microcode program and calling a microcode program provided by an embodiment of the present application. Fig.14 As shown in the figure, the real-time microcode program unloading process on the host side is as follows Fig.14 As shown by the black solid line with arrow in FIG. Specifically, the method includes the following steps.

[0171] 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, where the RPC server program is the target microcode program to be uninstalled. The DPU application can be, for example, a storage application, a network application, a security application, or a virtualization application.

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

[0173] Step (3): The runtime RPC controller on the host will assign a logical address to the target microcode program according to 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 meta-information about the target microcode program, including the function identifier, logical address, and user identifier.

[0174] 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 is captured by the hardware scheduler in the DPU.

[0175] Step (5): The hardware scheduler determines that the first static microcode program (i.e., function_offload) should be executed according to the reserved field (i.e., the first indication information) in the first message 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 conversion rules to save the received instructions.

[0176] like Fig.14 As shown, the real-time calling microcode program process on the host side is as follows Fig.14 As shown by the black dotted line with an arrow in FIG. Specifically, the method comprises the following steps.

[0177] 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).

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

[0179] 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 through the function identifier and logical address, and passes in parameters for execution, and finally returns the execution result to the RPC client program.

[0180] in addition, Fig.14The RPC framework shown is also compatible with the call of DPU microcode based on the "firmware update" mode. The specific process is as follows Fig.14 The black dotted line with arrows is shown in the figure. Fig.14 As shown, 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 according to 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.

[0181] In summary, the microcode thread calling process provided by the embodiment of the present application greatly increases the number of microcode programs that can be supported on the DPU, breaking through the use bottleneck of the DPU. At the same time, for the remote host, the microcode thread call on the DPU can be realized through unilateral RDMA, so that the performance can be improved by 3-6 times. Fig.15 It is a performance comparison schematic diagram provided in an embodiment of the present application. Fig.15 Solution 1 is to burn the microcode program into the DPU in the form of firmware when the computer is turned on. Solution 2 is Fig.14 The microcode thread offloading and calling scheme is shown in . Fig.15 As shown in the figure, compared with Solution 1, Solution 2 has a significant improvement in the throughput (in units: operations per second, OPS / s) performance when writing data to the DPU (i.e., unloading the microcode program). In addition, Fig.15 Solution 2 reads data from the DPU, representing the host calling the microcode program in the DPU.

[0182] In addition, as the use scenarios of DPU expand, more and more microcode programs are offloaded to DPU, and even different microcode programs need to use DPU for calculation at the same time. When different microcode programs use the same DPU at the same time, it is necessary to ensure that resources are used effectively while ensuring security.

[0183] In some scenarios, due to the limited memory and other resources of the DPU, it may not be possible to load all registered microcode programs. In addition, different microcode programs require different memory spaces. In order to ensure the efficiency of remote calls of microcode programs, it is necessary to design a microcode management strategy that can achieve load balancing.

[0184] 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., loaded), the target microcode program is directly called; otherwise, the target microcode program is unloaded to the DPU and the existence flag is set to 1. In this process, if the memory of the DPU is insufficient, such as there are not enough logical addresses currently allocated to the target microcode program, the least recently used (LRU) strategy is used to evict a microcode program in the function table, that is, the microcode program is deleted from the DPU and the table entry corresponding to the microcode program in the function table is deleted. The LRU strategy can ensure that the function table will not be occupied by a short-term microcode program, resulting in a denial-of-service (DoS) attack.

[0185] In addition, to avoid memory fragmentation, the host can use a buddy allocator to manage the logical address of the DPU's memory, so that the memory can be reused when the microcode program is unloaded or deleted (that is, swapped in or out). In addition, to ensure load balancing, the DPU's hardware scheduler can also use time-sharing multiplexing and low-frequency priority strategies, so that the unloading or calling of different microcode programs can be fairly distributed to each hardware of the DPU.

[0186] Through the above load balancing strategy, the DPU throughput can be increased by about 3.57 times, and the latency can be reduced by about 40.9%-59.5%.

[0187] In other scenarios, it is also necessary to authenticate the remote microcode program calls initiated by users to avoid user error calls and malicious attacks. At the same time, when calling microcode programs, it is necessary to ensure that different microcode programs do not call the data of other microcode programs, thereby violating isolation. Therefore, it is also necessary to design microcode management strategies that can achieve security.

[0188] In the embodiments of the present application, Fig.16 As shown, 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 to the host's runtime RPC controller. At the same time, the key is transmitted to the client program through a secure communication channel. After obtaining the secret key, the host can also add the secret key to the function table to obtain an extended function table. Fig.17 Schematic diagram of an extended function table provided in an embodiment of the present application. Fig.17As shown, the extended function table includes information such as function identification, user identification, logical address, key, priority, and existence flag bit for the target microcode program.

[0189] like Fig.16 As shown, when calling the target microcode program, the client program is accompanied by an okey' and its request content. The request content is, for example, the parameters required to execute the target microcode program. When the RPC controller queries the function table at runtime, it verifies the permission (okey=okey') and then calls the target microcode program on the DPU. Since only the registrant itself has 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 permission management mechanism.

[0190] In addition, in the implementation of the present 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), and the function table will be removed, and an error warning message will be thrown.

[0191] In addition, in order to ensure the isolation of the microcode program itself (a microcode program will not call the data of another program), such as Fig.16 As shown, the host can use a trusted third party (such as the developer of this firmware) to calculate the hash and sign the target microcode program using a hash tool such as secure hash algorithm (SHA) 256. 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.

[0192] Fig.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, and the firmware of the DPU includes a first static microcode program; Fig.18 As shown, the device 1800 includes the following modules.

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

[0194] 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. For specific implementation methods, please refer to Figure 6 Step 605 in an embodiment.

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

[0196] 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;

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

[0198] Optionally, the first receiving module is used for:

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

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

[0201] The device also includes:

[0202] A second receiving module, used for receiving a second message from the host, the second message carrying second indication information, parameters and logic addresses required for executing the target microcode program;

[0203] 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 a parameter;

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

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

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

[0207] The device also includes:

[0208] A third receiving module, used for receiving a third message from the host, the third message carrying third indication information and a user identifier of the target microcode program;

[0209] A third execution module, 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;

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

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

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

[0213] 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 extended. 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 carrying the first indication information and the microcode program to be unloaded in the message.

[0214] It should be noted that: the device for unloading the microcode program provided in the above embodiment only uses the division of the above functional modules as an example when unloading the 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 is divided into different functional modules to complete all or part of the functions described above. In addition, the device for unloading the microcode program provided in the above embodiment and the method embodiment for unloading the microcode program belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0215] Fig.19 1900 is a schematic diagram of another device for uninstalling a microcode program provided in an embodiment of the present application. 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 1900 includes:

[0216] The first acquisition module 1901 is used to obtain 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. For specific implementation methods, please refer to Figure 6 Step 601 in the embodiment.

[0217] The second acquisition module 1902 is used to acquire the logical address allocated to the target microcode program based on the user identifier of the target microcode program; the specific implementation method can refer to Figure 6 Step 602 in an embodiment.

[0218] The first sending module 1903 is used 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 the data after the program body of the target microcode program is compiled. The first indication information is used to instruct the DPU to execute a first static microcode program. 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. For specific implementation methods, please refer to Figure 6 Step 603 in the embodiment.

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

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

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

[0222] 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;

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

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

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

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

[0227] Optionally, the device further comprises:

[0228] A third sending module is used to send 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;

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

[0230] The second message carries a function identifier.

[0231] 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 extended. 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 carrying the first indication information and the microcode program to be unloaded in the message.

[0232] It should be noted that: the device for unloading the microcode program provided in the above embodiment only uses the division of the above functional modules as an example when unloading the 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 is divided into different functional modules to complete all or part of the functions described above. In addition, the device for unloading the microcode program provided in the above embodiment and the method embodiment for unloading the microcode program belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0233] Fig. 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 Fig. 20 The computer device shown is implemented. Fig. 20 The computer device includes at least one processor 2001, a communication bus 2002, a memory 2003 and at least one communication interface 2004.

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

[0235] Communication bus 2002 may include a pathway for transmitting information between the above-mentioned components.

[0236] The memory 2003 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices 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, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a disk or other magnetic storage device, or any other medium that can be used to carry or store the 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.

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

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

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

[0240] 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 may display information in a variety of ways. For example, the output device 2006 may 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 may receive user input in a variety of ways. For example, the input device 2007 may be a mouse, a keyboard, a touch screen device, or a sensor device.

[0241] The above-mentioned computer device can be a general-purpose computer device or a special-purpose computer device. In a specific implementation, the computer device can 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 embodiment of the present application does not limit the type of computer device.

[0242] In addition, if Fig.21 As shown, the embodiment of the present application further provides a DPU 2100, which includes a processor 2101 and a memory 2102. The memory 2102 is used to store a program that supports the DPU to execute the method provided by the embodiment of the present application, and to store data involved in implementing the method provided by the embodiment of the present application; the processor 2101 is configured to execute the program stored in the memory. For example, the processor includes Figure 2 Multiple processing cores in the memory include Figure 2 SMF in.

[0243] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part 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, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may 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 may be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. 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)).

[0244] A person 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 instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0245] The above content is not intended to limit the embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the protection scope 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: A second receiving module, configured to receive a second message from the host, wherein the second message carries second indication information, parameters required for executing the target microcode program, and the logical address; 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: A third sending module is used to send 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; 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