Accelerator card management method and apparatus, and device, non-volatile readable storage medium, product and system

Abstract

Disclosed in the present application are an accelerator card management method and apparatus, and a device, a non-volatile readable storage medium, a product and a system in the technical field of computers. In the present application, a baseboard management controller constructs a corresponding management command in the protocol format of the same target protocol, so as to manage at least one accelerator card, such that unified management over multiple types of accelerator cards can be realized; and for the same accelerator card, the constructed management command comprises at least one of the following: a static-information-type command, a dynamic-information-type command, a diagnostic-information-type command, or a firmware-maintenance-type command. Therefore, comprehensive information management can be implemented for the accelerator card, thereby facilitating stable operation of the accelerator card.

Description

A method, apparatus, device, non-volatile readable storage medium, product, and system for managing accelerator cards.

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202411206149.5, filed on August 30, 2024, entitled "A method, apparatus, device, medium, product and system for managing accelerator cards", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of computer technology, and in particular to an accelerator card management method, apparatus, device, non-volatile readable storage medium, product, and system. Background Technology

[0004] Accelerator card management is not only about resource scheduling and task allocation, but also about energy efficiency and cost control. Currently, there is a lack of unified standards for accelerator card management. Accelerator cards designed by different manufacturers exhibit significant differences in management methods. This leads to inconsistencies in information acquisition across different types of accelerator cards and a wide variety of information acquisition command formats, posing significant challenges to the adaptation of baseboard management controllers. Furthermore, accelerator cards are often configured to compute AI (Artificial Intelligence) models, and the rapid computation of these AI models depends on the stability of the accelerator cards.

[0005] Therefore, there are technical problems in the related technologies that prevent comprehensive management of accelerator cards. Summary of the Invention

[0006] In view of this, the purpose of this application is to provide an accelerator card management method, apparatus, device, non-volatile readable storage medium, product, and system for more comprehensive management of accelerator cards. The optional solutions are as follows:

[0007] According to the first aspect, this application provides an accelerator card management method applied to a baseboard management controller, wherein the baseboard management controller is connected to at least one accelerator card via a target bus;

[0008] The method includes:

[0009] The target bus driver and the target protocol driver are loaded using the operating system deployed on the core of the baseboard management controller.

[0010] If at least one accelerator card is detected, management commands are constructed for at least one accelerator card according to the protocol format of the target protocol; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands;

[0011] Management commands are sent to at least one accelerator card via the target bus.

[0012] In some embodiments, the target bus driver and the target protocol driver are loaded using an operating system deployed on the core of the baseboard management controller, including:

[0013] After the baseboard management controller is powered on, the real-time operating system deployed on the first core of the baseboard management controller is started.

[0014] The target bus driver and target protocol driver are loaded using the real-time operating system after startup.

[0015] In some embodiments, management commands are built for at least one accelerator card according to the protocol format of the target protocol, including:

[0016] The command fields are determined according to the protocol format; the command fields include: message type flag and command code;

[0017] Based on the command fields, static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands are constructed. Among them, the message type flags corresponding to different types of management commands are different, and different commands within the same type of management commands correspond to different command codes.

[0018] In some embodiments, static information class commands include at least one of the following: accelerator card hardware version query command, accelerator card manufacturer number query command, accelerator card product number query command, accelerator card product serial number query command, accelerator card manufacturing time query command, and accelerator card firmware version query command.

[0019] Accordingly, the message type flag in the command field is set as the first flag, and different commands in the static information class command correspond to different command codes;

[0020] Accordingly, if at least one accelerator card is detected and / or a static information query command is detected, a static information class command is constructed for at least one accelerator card in accordance with the protocol format.

[0021] In some embodiments, dynamic information commands include at least one of the following: accelerator card temperature query command, accelerator card power consumption query command, accelerator card voltage query command, link negotiation bandwidth query command between accelerator card and host, link negotiation rate query command between accelerator card and host, and accelerator card processor utilization query command.

[0022] Accordingly, the message type flag in the command field is set as the second flag, and different commands in the dynamic information class command correspond to different command codes;

[0023] Accordingly, when at least one accelerator card is detected to be in operation, dynamic information class commands are periodically constructed for at least one accelerator card in accordance with the protocol format.

[0024] In some embodiments, diagnostic information commands include at least one of the following: accelerator card health status query command, accelerator card return review status query command, accelerator card high-speed serial computer expansion bus error count query command, accelerator card memory error count query command, accelerator card peripheral error count query command, accelerator card correction code error count query command, uncorrectable error status register query command, uncorrectable error mask register query command, uncorrectable error level register query command, correctable error status register query command, correctable error mask register query command, correctable error level register query command, advanced error reporting control register query command, advanced error reporting header log register query command, and advanced error reporting transaction layer packet log register query command;

[0025] Accordingly, the message type flag in the command field is determined to be the third flag, and different commands in the diagnostic information class commands correspond to different command codes;

[0026] Accordingly, when a diagnostic command for at least one accelerator card is detected, diagnostic information class commands are periodically constructed for at least one accelerator card in accordance with the protocol format.

[0027] In some embodiments, firmware upgrade commands include: accelerator card firmware protection status query command, accelerator card firmware protection status setting command, accelerator card firmware upgrade command, accelerator card system reset command, and accelerator card power on / off command;

[0028] Accordingly, the message type flag in the command field is determined to be the fourth flag, and different commands in the firmware upgrade command class correspond to different command codes;

[0029] Accordingly, if a firmware upgrade command for at least one accelerator card is detected, a firmware upgrade class command is constructed for at least one accelerator card in accordance with the protocol format.

[0030] In some embodiments, the command field further includes: a data integrity check bit, an accelerator card identification bit, a total number of data packets flag bit, a data packet count flag bit, a return data length, a data payload, and a check bit.

[0031] In some embodiments, the target bus driver and the target protocol driver are loaded using an operating system deployed on the core of the baseboard management controller, including:

[0032] After the baseboard management controller is powered on, the real-time operating system deployed on the first core of the baseboard management controller is started.

[0033] The target bus driver and target protocol driver are loaded using the real-time operating system after startup.

[0034] In some embodiments, the target bus driver and the target protocol driver are loaded using an operating system deployed on the core of the baseboard management controller, including:

[0035] After the baseboard management controller is powered on, the non-real-time operating system deployed on the second core of the baseboard management controller is started;

[0036] The driver for the target bus and the driver for the target protocol are loaded using the non-real-time operating system after startup.

[0037] In some embodiments, a real-time operating system is deployed on the first core of the baseboard management controller, and the non-real-time operating system and the real-time operating system establish inter-core communication.

[0038] Accordingly, management commands are built for at least one accelerator card according to the protocol format of the target protocol, including:

[0039] Using a non-real-time operating system, management commands not constructed according to the protocol format are sent to the real-time operating system via inter-core communication;

[0040] The real-time operating system is used to convert management commands that are not constructed according to the protocol format into management commands that are constructed according to the protocol format.

[0041] In some embodiments, the non-real-time operating system and the real-time operating system share the target memory region in the first core or the second core.

[0042] Accordingly, using a non-real-time operating system to send management commands not constructed according to the protocol format to the real-time operating system via inter-core communication includes:

[0043] The non-real-time operating system is used to write management commands that are not constructed according to the protocol format into the target memory area, and the real-time operating system is notified by inter-core interrupts.

[0044] The real-time operating system is used to read management commands from the target memory area that are not constructed according to the protocol format.

[0045] In some embodiments, at least one accelerator card is connected to the host via a preset communication protocol;

[0046] Correspondingly, it also includes:

[0047] The system receives accelerator card management commands from the host via a preset communication protocol.

[0048] In some embodiments, it also includes:

[0049] Receive response data from at least one accelerator card in response to management commands.

[0050] According to the second aspect, this application provides an accelerator card management device applied to a baseboard management controller, wherein the baseboard management controller is connected to at least one accelerator card via a target bus;

[0051] The device includes:

[0052] The system control module is configured to load the target bus driver and the target protocol driver using the operating system deployed on the core of the baseboard management controller.

[0053] The command building module is configured to build management commands for at least one accelerator card according to the protocol format of the target protocol when at least one accelerator card is detected; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands;

[0054] The command sending module is configured to send management commands to at least one accelerator card via the target bus.

[0055] According to a third aspect, this application provides an electronic device, comprising:

[0056] The memory is configured to store computer programs;

[0057] The processor is configured to execute computer programs to implement the aforementioned disclosed accelerator card management method.

[0058] According to the fourth aspect, this application provides a non-volatile readable storage medium configured to store a computer program, wherein the computer program, when executed by a processor, implements the aforementioned accelerator card management method.

[0059] According to a fifth aspect, this application provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the aforementioned disclosed accelerator card management method.

[0060] According to the sixth aspect, this application provides an accelerator card management system, including: a baseboard management controller and at least one accelerator card;

[0061] The baseboard management controller is connected to at least one accelerator card via a target bus;

[0062] The baseboard management controller is configured to: load the target bus driver and the target protocol driver using the operating system deployed on its core; when at least one accelerator card is detected, construct management commands for at least one accelerator card according to the protocol format of the target protocol; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands; and send the management commands to at least one accelerator card via the target bus.

[0063] In some embodiments, the accelerator card management system further includes: a host;

[0064] At least one accelerator card is connected to the host via a preset communication protocol;

[0065] The host is configured to: send computing tasks to at least one accelerator card via a preset communication protocol; and send accelerator card management instructions to the baseboard management controller via a preset communication protocol.

[0066] In some embodiments, the baseboard management controller includes at least two cores; a real-time operating system is deployed on the first core, and a non-real-time operating system is deployed on the second core.

[0067] The non-real-time operating system and the real-time operating system establish inter-core communication. The non-real-time operating system communicates with at least one accelerator card through inter-core communication with the real-time operating system; or the non-real-time operating system and the real-time operating system communicate independently with at least one accelerator card.

[0068] As can be seen from the above scheme, this application provides an accelerator card management method, applied to a baseboard management controller, which connects to at least one accelerator card via a target bus; the method includes: loading the target bus driver and the target protocol driver using an operating system deployed on the core of the baseboard management controller; when at least one accelerator card is detected, constructing management commands for at least one accelerator card according to the protocol format of the target protocol; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands; and sending the management commands to at least one accelerator card via the target bus.

[0069] As can be seen, the beneficial effects of this application are as follows: the baseboard management controller constructs corresponding management commands in the same target protocol format to manage at least one accelerator card, which can realize unified management of multiple types of accelerator cards. Furthermore, for the same accelerator card, the constructed management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands. This enables more comprehensive information management of the accelerator card and is conducive to the stable operation of the accelerator card.

[0070] Accordingly, the accelerator card management device, equipment, non-volatile readable storage medium, product and system provided in this application also have the above-mentioned technical effects. Attached Figure Description

[0071] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0072] Figure 1 is a flowchart of an accelerator card management method disclosed in this application;

[0073] Figure 2 is a schematic diagram of the format of a management command received by an accelerator card disclosed in this application;

[0074] Figure 3 is a schematic diagram of the format of a command sent by an accelerator card disclosed in this application;

[0075] Figure 4 is a schematic diagram of an accelerator card management system disclosed in this application;

[0076] Figure 5 is a flowchart of the management method corresponding to the system shown in Figure 4;

[0077] Figure 6 is a schematic diagram of another accelerator card management system disclosed in this application;

[0078] Figure 7 is a flowchart of the management method corresponding to the system shown in Figure 6;

[0079] Figure 8 is a server structure diagram provided in this application;

[0080] Figure 9 is a terminal structure diagram provided in this application. Detailed Implementation

[0081] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other instances obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0082] Currently, accelerator card management is not only related to resource scheduling and task allocation, but also to energy efficiency and cost control. The current management of accelerator cards lacks a unified standard, and the management methods of accelerator cards designed by different manufacturers vary significantly. This leads to inconsistencies in information acquisition from different types of accelerator cards and also results in widely different information acquisition command formats, posing significant challenges to the adaptation of the baseboard management controller. Furthermore, accelerator cards are often used to compute AI models, and the rapid computation of AI models depends on the stability of the accelerator cards. Therefore, this application provides an accelerator card management solution that enables more comprehensive management of accelerator cards.

[0083] This application discloses an accelerator card management method applied to a baseboard management controller. The baseboard management controller connects to at least one accelerator card via a target bus (such as I2C). When there are multiple accelerator cards, they may be of different or the same type, such as GPU (Graphics Processing Unit), FPGA (Field-Programmable Gate Array), etc. I2C (Inter-Integrated Circuit) is a bidirectional two-wire synchronous serial bus.

[0084] Referring to Figure 1, the accelerator card management method disclosed in this application includes:

[0085] S101. Load the target bus driver and the target protocol driver using the operating system deployed on the core of the baseboard management controller.

[0086] In this embodiment, the baseboard management controller includes at least one core, on which an independent operating system is deployed. In one example, the baseboard management controller includes two cores: a first core deploying a real-time operating system (RTOS) and a second core deploying a non-RTOS, such as Linux. Compared to a non-RTOS, the ROS executes commands faster, and it is not limited to operating systems; it can also be a bare-metal program without an operating system, such as a program for a microcontroller. The operating system loads the target bus driver and the target protocol driver, enabling communication between the baseboard management controller and at least one accelerator card, providing a communication foundation for the construction and transmission of subsequent management commands.

[0087] In one implementation, the operating system deployed on the core of the baseboard management controller loads the driver for the target bus and the driver for the target protocol (such as MCTP). This includes: after the baseboard management controller is powered on, starting the real-time operating system deployed on the first core of the baseboard management controller; and using the started real-time operating system to load the driver for the target bus and the driver for the target protocol. That is, the started real-time operating system constructs management commands according to the protocol format of the target protocol and communicates with at least one accelerator card. MCTP is a management component transport protocol.

[0088] In one implementation, the target bus driver and target protocol driver are loaded using an operating system deployed on the core of the baseboard management controller. This includes: after the baseboard management controller is powered on, starting a non-real-time operating system deployed on a second core of the baseboard management controller; and using the started non-real-time operating system to load the target bus driver and target protocol driver. That is, the started non-real-time operating system constructs management commands according to the target protocol's protocol format and communicates with at least one accelerator card.

[0089] In one implementation, a real-time operating system (RTOS) is deployed on a first core of the baseboard management controller, and a non-real-time operating system (NRS) and the ROS establish inter-core communication. Accordingly, management commands are constructed for at least one accelerator card according to the protocol format of the target protocol, including: sending management commands not constructed according to the protocol format to the ROS via inter-core communication using the NRS; and converting the management commands not constructed according to the protocol format into management commands constructed according to the protocol format using the ROS. The NRS and the ROS share a target memory area in the first or second core. Correspondingly, sending management commands not constructed according to the protocol format to the ROS via inter-core communication using the NRS includes: writing the management commands not constructed according to the protocol format to the target memory area using the NRS and notifying the ROS using an inter-core interrupt; and reading the management commands not constructed according to the protocol format from the target memory area using the ROS. In this example, the non-real-time operating system, after startup, cannot construct management commands according to the target protocol's format and cannot communicate directly with at least one accelerator card. It needs the help of a real-time operating system to convert the non-prototyped management commands into those conforming to the target protocol's format before sending them to at least one accelerator card. This improves the real-time performance of command transmission, making it possible to perform tasks with high real-time requirements even within the non-real-time operating system. In other words, the real-time operating system performs the command encapsulation function in this process.

[0090] S102. If at least one accelerator card is detected, construct management commands for at least one accelerator card according to the protocol format of the target protocol; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands.

[0091] It should be noted that after communication between the baseboard management controller and at least one accelerator card is established, the baseboard management controller sequentially scans each accelerator card to detect its availability. In one embodiment, at least one accelerator card is scanned sequentially via a target bus, and the scanned accelerator card is designated as the managed accelerator card. If necessary, the baseboard management controller can update and record the identity information, bus address, and other information of each scanned accelerator card in real time.

[0092] In one implementation, management commands are constructed for at least one accelerator card according to the protocol format of the target protocol. This includes: determining command fields according to the protocol format; the command fields include at least one of the following: data integrity check bit, message type flag bit, accelerator card identification bit, command code, total data packet count flag bit, data packet count flag bit, return data length, data payload, and checksum bit; and constructing static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands based on the command fields. Different types of management commands correspond to different message type flag bits, and different commands within the same type of management command correspond to different command codes. Thus, each type of management command is distinguished by different message type flag bits, and different sub-commands within the same type of management command are further distinguished by different command codes. This two-level division provides the possibility for subsequent command expansion. For example, message type flag bits can be added to expand the types of management commands; correspondingly, the sub-commands under each type of management command can be expanded by adding more command codes.

[0093] If the static information class commands include at least one of the following: accelerator card hardware version query command, accelerator card manufacturer number query command, accelerator card product number query command, accelerator card product serial number query command, accelerator card manufacturing time query command, and accelerator card firmware version query command; accordingly, the message type flag bit in the command field is determined to be the first flag bit, and different commands in the static information class commands correspond to different command codes. Accordingly, when at least one accelerator card is scanned and / or a static information query command is detected, a static information class command is constructed for at least one accelerator card according to the protocol format. That is, when the BMC (Board Management Controller) completes the scan of an accelerator card or detects a static information query command sent by the user to the BMC through the host, the construction and sending of the static information class commands will be triggered.

[0094] If the dynamic information class commands include at least one of the following: accelerator card temperature query command, accelerator card power consumption query command, accelerator card voltage query command, link negotiation bandwidth query command between accelerator card and host, link negotiation rate query command between accelerator card and host, and accelerator card processor utilization query command; accordingly, the message type flag bit in the command field is determined to be the second flag bit, and different commands in the dynamic information class commands correspond to different command codes. Accordingly, when at least one accelerator card is detected to be in operation, dynamic information class commands are periodically constructed for at least one accelerator card according to the protocol format. That is, during accelerator card operation, accelerator card dynamic information is periodically and dynamically detected.

[0095] If the diagnostic information commands include at least one of the following: accelerator card health status query command, accelerator card return review status query command, accelerator card high-speed serial computer expansion bus error count query command, accelerator card memory error count query command, accelerator card peripheral error count query command, accelerator card correction code error count query command, uncorrectable error status register query command, uncorrectable error mask register query command, uncorrectable error level register query command, correctable error status register query command, correctable error mask register query command, correctable error level register query command, advanced error reporting control register query command, advanced error reporting header log register query command, and advanced error reporting transaction layer packet log register query command. The aforementioned commands are, in order: Accelerator card health status query command, Accelerator card RMA (Return Merchandise Authorization) status query command, Accelerator card PCIe (Peripheral Component Interconnect Express) error count query command, Accelerator card memory error count query command, Accelerator card peripheral error count query command, Accelerator card ECC (Error-Correcting Code) error count query command, UCE (Uncorrectable Error) status register query command, UCE mask register query command, UCE level register query command, CE (Correctable Error) status register query command, CE mask register query command, CE level register query command, AER (Advanced Error Reporting) control register query command, AER HDRLOG (Advanced Error Reporting Header Log) register query command, and AER TLPLOG (Advanced Error Reporting Transaction Layer Packet) register query command. Log (Advanced Error Reporting Transaction Layer Packet Log) register query command; accordingly, determine that the message type flag in the command field is the third flag, and determine that different commands in the diagnostic information class commands correspond to different command codes. Accordingly, when a diagnostic command for at least one accelerator card is detected, a diagnostic information class command is periodically constructed for at least one accelerator card according to the protocol format. That is, the construction and transmission of diagnostic information class commands need to be triggered by the diagnostic commands of the accelerator cards. The host can send diagnostic commands for the accelerator cards to the BMC. In some embodiments, when the host operating system detects an anomaly in an accelerator card, it sends the diagnostic command for that accelerator card to the BMC.

[0096] If the firmware upgrade commands include: accelerator card firmware protection status query command, accelerator card firmware protection status setting command, accelerator card firmware upgrade command, accelerator card system reset command, and accelerator card power on / off command; accordingly, the message type flag bit in the command field is determined to be the fourth flag bit, and different commands in the firmware upgrade commands correspond to different command codes. Accordingly, when at least one accelerator card firmware upgrade instruction is detected, firmware upgrade commands are constructed for at least one accelerator card according to the protocol format. That is, firmware upgrade commands need to be triggered by the accelerator card firmware upgrade instruction to be constructed and sent. Specifically, the user sends the accelerator card firmware upgrade instruction to the BMC through the host.

[0097] In this embodiment, four types of management commands—static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands—allow for comprehensive information querying and monitoring of the same accelerator card. These commands can collect static information such as the accelerator card's basic identity (e.g., product number), dynamic information such as temperature and power consumption during operation, diagnostic information for fault diagnosis, and firmware management. This facilitates stable operation of the accelerator card during model computation. Furthermore, each type of management command is distinguished by different message type flags, and different sub-commands within the same management command type are further distinguished by different command codes. This two-level division allows for the expansion of subsequent commands. For example, message type flags can be added to expand the types of management commands, and correspondingly, the sub-commands under each management command type can be expanded by adding more command codes.

[0098] S103. Send management commands to at least one accelerator card via the target bus.

[0099] In one implementation, at least one accelerator card is connected to the host via a preset communication protocol; correspondingly, the system also includes receiving accelerator card management commands sent by the host via the preset communication protocol. That is, the BMC is controlled by the host to manage at least one accelerator card. The BMC also receives response data from the managed accelerator card in response to the management commands sent to it. This response data may include relevant information about the accelerator card that the BMC wants to know, such as at least one of the four types of information mentioned above. If the MCTP protocol is used, the format of the response data can be constructed with reference to Figure 3, Table 3, and Table 4.

[0100] As can be seen, in this embodiment, the baseboard management controller constructs corresponding management commands in the same target protocol format to manage at least one accelerator card, which can realize unified management of multiple types of accelerator cards. For the same accelerator card, the constructed management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands. This enables more comprehensive information management of the accelerator card, which is beneficial to the stable operation of the accelerator card.

[0101] The following example uses MCTP to illustrate the field definitions in management commands. In the MCTP format, Byte00 to Byte03 are the standard MCTP message headers, which should conform to the MCTP protocol definition. This example defines the fields from Byte04 onwards.

[0102] Optionally, please refer to Figure 2, which shows the format of management commands received by the accelerator card. The definitions of each field are provided in Tables 1 and 2. Table 1 shows the original definitions of the MCTP protocol, while Table 2 shows the accelerator card-related information customized for this example according to the MCTP protocol. Furthermore, for the format shown in Figure 2, Bytes 00 to 03 are standard MCTP message headers, which only need to conform to the MCTP protocol. Byte 11 is the Completion Code, used to indicate the status of the AI ​​accelerator card (such as correct command response, command response timeout, etc.). The definition of this field can be used by the BMC management unit to quickly understand the command response status, improving command interaction efficiency. The definitions of the remaining fields ensure the accelerator card's flexible, efficient, reliable, and unified management functions.

[0103] Table 1

[0104] Table 2

[0105] Please refer to Figure 3, which shows the format of commands sent by the accelerator card (e.g., responses to commands sent by the BMC). The definitions of each field are provided in Tables 3 and 4. Table 3 shows the original definitions of the MCTP protocol, while Table 4 shows the accelerator card-related information customized for this example according to the MCTP protocol.

[0106] Table 3

[0107] Table 4

[0108] As shown in Figures 2 and 3, and Tables 1-4, Byte 10 and Byte 11 correspond to Command Type and Command Code, respectively. These two fields jointly define the commands that the accelerator card needs to support. By defining the Command Type, the management commands of the accelerator card can be quickly classified. Within the corresponding category, the Command Code further distinguishes the commands. This design improves the scalability of the accelerator card's management command set, facilitating the definition of more commands in the future. At the same time, through joint definition, it is convenient for the BMC management unit and AI accelerator card components to classify commands in an orderly manner, improving command management efficiency. In addition, Byte 12 and Byte 13 correspond to Total Packets and Packet Number, respectively. These two fields are used to identify the current command transmission status and can be used for status management during long data packet transmissions (such as image file transmission during firmware upgrades), enabling support for more management functions related to the AI ​​accelerator card. The fields from Byte 14 onwards constitute the data body corresponding to the command. This part supports data length constraints (via the Payload Len field) and data verification (Check Sum field), which can effectively improve the data parsing rate of the receiving end and the reliability of command transmission. By using the AI ​​accelerator card management message format proposed in this application, the goals of flexible, efficient, reliable, and unified management of AI accelerator cards can be achieved.

[0109] In this example, the accelerator card management commands can include four categories: static information, dynamic information, diagnostic information, and firmware upgrade commands. The detailed commands under each category are shown in Tables 5 through 8. Table 5 shows the set of management commands for static information (Command Type: 0), Table 6 shows the set of management commands for dynamic information (Command Type: 1), Table 7 shows the set of management commands for diagnostic information (Command Type: 2), and Table 8 shows the set of management commands for firmware upgrades (Command Type: 3). RO indicates a read-only operation. W indicates a write operation.

[0110] Table 5

[0111] Of course, static information management commands include, but are not limited to, the commands listed in Table 5. Actual commands can be expanded according to application scenarios. The hardware version number command (Command Code: 0x00) in Table 5 is used to obtain the hardware version number. In practical applications, after obtaining the hardware version number, BMC can quickly determine whether the accelerator card belongs to the supported component list when adapting server accelerator cards, improving adaptation efficiency.

[0112] Table 6

[0113] Of course, dynamic information management commands include, but are not limited to, the commands listed in Table 6. Actual commands can be extended according to application scenarios. Table 6 shows the PCIe link coordination bandwidth and PCIe link negotiation rate (Command Code: 0x03 and 0x04). This command is used to obtain the PCIe link coordination bandwidth. In practical applications, the BMC management unit can promptly grasp the link bandwidth and link rate of the accelerator card, providing a basis for analyzing the PCIe link throughput performance of the accelerator card.

[0114] Table 7

[0115] Of course, diagnostic information management commands include, but are not limited to, the commands listed in Table 7. Actual commands can be extended according to application scenarios. Table 7 lists commands for retrieving registers strongly related to PCIe link faults, such as the PCIe UCE status register, PCIe UCE mask register, PCIe UCE level register, PCIe CE status register, PCIe CE mask register, PCIe AER control register, PCIe AER HDRLOG register, and PCIe AER TLPLOG register. These registers record detailed information about AI accelerator card faults, including faults in CE, UCE, and AER. These commands are crucial for fault analysis when AI accelerator cards malfunction, helping to quickly define and resolve AI accelerator card faults.

[0116] Table 8

[0117] Of course, firmware upgrade management commands include, but are not limited to, the commands listed in Table 8. The actual commands can be expanded according to the application scenario. In Table 8, the system reset command is used to reset the entire board and the main chip of the AI ​​accelerator card. This operation, in conjunction with the firmware upgrade operation, enables the out-of-band reset function after the accelerator card upgrade, avoiding the need to restart the entire server system after the accelerator card upgrade, and minimizing the impact of the AI ​​accelerator card upgrade operation on the host-side business.

[0118] After defining the command format according to this embodiment, it is applied to the system shown in Figure 4. As shown in Figure 4, under the control of a single CPU (Central Processing Unit), multiple AI accelerator cards are set up. These accelerator cards are connected to the BMC via the I2C bus and to the CPU via PCIe. The overall architecture can be divided into three parts: the BMC unit, the AI ​​accelerator unit, and the CPU unit.

[0119] The BMC unit contains a control core, typically an ARM (Advanced RISC Machines) processor, on which runs the BMC management system. In this application, the BMC unit has multiple control cores (Figure 4 shows two), and different operating systems run on different cores, constructing a heterogeneous server management system. In some embodiments, Core1 of the BMC in Figure 4 runs an RTOS (Real-Time Operating System), and Core2 runs a Linux system. RTOS systems are lightweight and highly real-time, excelling at handling time-sensitive business; Linux systems feature multi-process, multi-task parallel execution, excelling at handling complex management tasks.

[0120] In Figure 4, the RTOS system interacts directly with the BMC I2C hardware controller to send and receive AI accelerator card management commands. The Linux system within the BMC management unit can also send and receive AI accelerator card management commands, but this requires indirect implementation through the RTOS system. The RTOS and Linux systems interact via inter-core communication. Furthermore, the RTOS system includes two modules: command sending and command receiving, responsible for sending and receiving management commands respectively. The command sending module consists of a command request module 2 and an MCTP message encapsulation module, responsible for generating the actual management commands and assembling and sending the final MCTP messages, respectively. Correspondingly, the command receiving module consists of MCTP message parsing and command response modules 2, responsible for receiving and parsing MCTP response data packets from the AI ​​accelerator card and extracting the actual response data, respectively. The management function for the AI ​​accelerator card in the Linux system also consists of command sending and command receiving modules. These modules are relatively simpler than those in the RTOS system, containing only command request 1 and command response 1 modules, responsible for sending and receiving AI accelerator card management commands, respectively. That is, the command sending and command receiving modules in the Linux system cannot construct or parse MCTP data packets.

[0121] In some embodiments, the AI ​​acceleration unit includes different AI acceleration cards, such as AI acceleration card 1, AI acceleration card 2...AI acceleration card N in the figure. These acceleration cards can be any of the FPGA, SOC, or ASIC architectures. Each AI acceleration card is connected to the CPU via a PCIe channel and to the I2C bus via an I2C controller, thereby enabling the interaction of acceleration card management information with the BMC management unit.

[0122] The CPU unit is the computing unit, responsible for system management and logical operations, and connects to the AI ​​acceleration unit via a PCIe channel. It collaborates with the AI ​​acceleration unit to significantly improve system computing speed.

[0123] It's worth noting that the heterogeneous management system (RTOS and Linux systems) within the BMC management unit not only improves the utilization of computing resources and enhances its management performance, but also fully leverages the advantages of the RTOS system to achieve high real-time management of AI accelerator cards. This allows for timely acquisition of the AI ​​accelerator card's operational status and the implementation of effective management measures when managing large-scale accelerator cards. The MCTP message design used in the RTOS system fully utilizes the media-independent nature of the MCTP protocol, greatly simplifying firmware development for different AI accelerator card management commands within the BMC, significantly improving the firmware development efficiency of the server BMC, and shortening the deployment time of AI accelerator cards.

[0124] To enable command transmission and interaction between the BMC's Linux and RTOS heterogeneous systems, this application designs a unified application-layer interface function based on an inter-core communication mechanism. By implementing this interface function in each heterogeneous system, the BMC's Linux and RTOS can support interaction of all accelerator card management commands. The interface function is defined as: void SendRecvIfc(int from_id, int to_id, char*buf, int len). Here, from_id is the operating system ID that initiates the BMC system command, and to_id is the operating system that receives the BMC system command. The ID for Linux is set to 1, and the ID for RTOS is set to 2. Buf is a pointer to the send (or receive) command buffer, and len is the data length of the send (or receive) command in bytes. When only a single operating system is running in the BMC management unit, this interface function does not need to be implemented.

[0125] In the structure shown in Figure 4, the management method for the AI ​​accelerator card can be divided into three stages: the management system startup stage, the inter-core communication establishment stage, and the management system normal stage, as shown in Figures 4 and 5.

[0126] Phase 1: Management System Startup Phase.

[0127] Step 1: The system is powered on, and the BMC's RTOS starts first;

[0128] Step 2: The BMC's Linux system starts up, and the BMC's RTOS system loads the I2C driver;

[0129] Step 3: The BMC RTOS system enters the AI ​​accelerator card management state, generates management commands through the command request module 2, and encapsulates them into MCTP Over I2C format for sending commands;

[0130] Step 4: The BMC's RTOS system transmits the encapsulated send command to the AI ​​accelerator card via the I2C channel through the I2C driver;

[0131] Step 5: Each AI accelerator card connected to the I2C bus listens to the bus status, compares its own I2C address with the address in the bus data packet, and the accelerator card with the matching address responds to the command request and prepares the MCTP Over I2C message.

[0132] Step 6: The AI ​​accelerator card with the matching address sends the above response message to the BMC's RTOS system via the I2C channel;

[0133] Step 7: After receiving the message on the I2C bus, the BMC's RTOS system parses the MCTP message and obtains command response 2, i.e., the response data.

[0134] Step 8: If there is a greater need for management of the AI ​​accelerator card at this stage, return to step 3.

[0135] Phase Two: Establishment of Inter-core Communication.

[0136] Step 1: The BMC's RTOS system loads the inter-core communication driver;

[0137] Step 2: Load the inter-kernel communication driver on the BMC's Linux system.

[0138] Phase 3: The normal operation phase of the management system.

[0139] Step ①: The Linux system of BMC sends command request 1 to the RTOS system of BMC via inter-kernel communication;

[0140] Step 2: The BMC's RTOS system converts Command Request 1 into Command Request 2 format and encapsulates it into a send command in MCTP Over I2C format;

[0141] Step 3: BMC's RTOS system transmits the encapsulated send command to the AI ​​accelerator card via the I2C channel through the I2C driver;

[0142] Step 4: Each AI accelerator card connected to the I2C bus listens to the bus status, compares its own I2C address with the address in the bus data packet, and the accelerator card with the matching address responds to the command request and prepares the MCTP Over I2C message.

[0143] Step 5: The AI ​​accelerator card with the matching address sends the above response message to the BMC's RTOS system via the I2C channel;

[0144] Step 6: After receiving the message on the I2C bus, the BMC's RTOS system parses the MCTP message and obtains command response 2, i.e., the response data;

[0145] Step 7: The BMC's RTOS system sends command response 2 to the BMC's Linux system via inter-core communication;

[0146] Step 8: The BMC's Linux system converts command response 2 into command response 1, thus obtaining the final response data;

[0147] Step 9: If there is a greater need for management of the AI ​​accelerator card at this stage, return to step 1.

[0148] In this embodiment, an RTOS system and a Linux system run on different cores of the BMC, respectively. This fully leverages the high real-time performance of the RTOS to directly interact with the accelerator card via management commands, improving accelerator card management efficiency while simultaneously enhancing the resource utilization of the entire BMC management unit. Furthermore, by defining a unified MCTP-based data link layer management message format and accelerator card management command set, a single BMC firmware can manage different types of accelerator cards, effectively improving the firmware adaptation efficiency of the server BMC management unit. In some embodiments, upon initial power-on of the BMC management unit, the BMC's RTOS system first interacts with the AI ​​accelerator card through a unified message format and command set. Then, after the BMC's Linux system boots normally, the BMC's RTOS system and the Linux system establish an inter-core communication mechanism, transmitting and interacting with accelerator card commands through the unified interaction interface defined in this application, achieving indirect and efficient management of the AI ​​accelerator card by the BMC's Linux system. The method proposed in this application has significant advantages in improving the firmware adaptation efficiency of the server BMC management unit, shortening the application deployment time of AI accelerator cards, improving AI accelerator card management efficiency, enhancing the utilization of BMC management unit computing resources, and controlling the overall server design cost.

[0149] Furthermore, the BMC management unit can run only the Linux operating system, as shown in Figure 6. Compared to Figure 4, Figure 6 eliminates the need to consider communication between heterogeneous management systems; the Linux system in the BMC management unit replaces the RTOS system in Figure 4, directly interacting with the AI ​​accelerator card. Correspondingly, the AI ​​accelerator card management method when only the Linux operating system is running in the BMC management unit is shown in Figure 7. Compared to Figure 5, this method eliminates the need to consider inter-core communication and command transmission processes between heterogeneous management systems; the Linux system in the BMC management unit directly interacts with the AI ​​accelerator card.

[0150] The following describes an accelerator card management device provided in an embodiment of this application. The accelerator card management device described below can be referred to in conjunction with other embodiments described herein.

[0151] This application discloses an accelerator card management device applied to a baseboard management controller, wherein the baseboard management controller is connected to at least one accelerator card via a target bus.

[0152] The accelerator card management device disclosed in this application includes:

[0153] The system control module is configured to load the target bus driver and the target protocol driver using the operating system deployed on the core of the baseboard management controller.

[0154] The command building module is configured to build management commands for at least one accelerator card according to the protocol format of the target protocol when at least one accelerator card is detected; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands;

[0155] The command sending module is configured to send management commands to at least one accelerator card via the target bus.

[0156] In one implementation, the system control module can be configured as follows:

[0157] After the baseboard management controller is powered on, the real-time operating system deployed on the first core of the baseboard management controller is started.

[0158] The target bus driver and target protocol driver are loaded using the real-time operating system after startup.

[0159] In one implementation, the command building module can be configured as follows:

[0160] The command fields are determined according to the protocol format; the command fields include at least one of the following: data integrity check bit, message type flag bit, accelerator card identity bit, command code, total number of data packets flag bit, number of data packets flag bit, return data length, data payload, and check bit; static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands are constructed based on the command fields.

[0161] In one implementation, the static information class commands include at least one of the following: accelerator card hardware version query command, accelerator card manufacturer number query command, accelerator card product number query command, accelerator card product serial number query command, accelerator card manufacturing time query command, and accelerator card firmware version query command; accordingly, the command construction module can be configured to: determine the message type flag bit in the command field as the first flag bit, and determine that different commands in the static information class commands correspond to different command codes.

[0162] In one implementation, the dynamic information class commands include at least one of the following: accelerator card temperature query command, accelerator card power consumption query command, accelerator card voltage query command, link negotiation bandwidth query command between accelerator card and host, link negotiation rate query command between accelerator card and host, and accelerator card processor utilization query command; accordingly, the command construction module can be configured to: determine the message type flag bit in the command field as the second flag bit, and determine that different commands in the dynamic information class commands correspond to different command codes.

[0163] In one implementation, the diagnostic information commands include at least one of the following: accelerator card health status query command, accelerator card return review status query command, accelerator card high-speed serial computer expansion bus error count query command, accelerator card memory error count query command, accelerator card peripheral error count query command, accelerator card correction code error count query command, uncorrectable error status register query command, uncorrectable error mask register query command, uncorrectable error level register query command, correctable error status register query command, correctable error mask register query command, correctable error level register query command, advanced error reporting control register query command, advanced error reporting header log register query command, and advanced error reporting transaction layer packet log register query command; correspondingly, the command construction module can be configured to: determine that the message type flag bit in the command field is the third flag bit, and determine that different commands in the diagnostic information commands correspond to different command codes.

[0164] In one implementation, the firmware upgrade commands include: accelerator card firmware protection status query command, accelerator card firmware protection status setting command, accelerator card firmware upgrade command, accelerator card system reset command, and accelerator card power on / off command; correspondingly, the command construction module can be configured to: determine the message type flag bit in the command field as the fourth flag bit, and determine that different commands in the firmware upgrade commands correspond to different command codes.

[0165] In one implementation, the system control module can be configured to: after the baseboard management controller is powered on, start a non-real-time operating system deployed on the second core of the baseboard management controller; and use the started non-real-time operating system to load the driver of the target bus and the driver of the target protocol.

[0166] In one implementation, a real-time operating system is deployed on the first core of the baseboard management controller, and a non-real-time operating system and the real-time operating system establish inter-core communication; accordingly, the command construction module can be configured to: use the non-real-time operating system to send management commands not constructed according to the protocol format to the real-time operating system via inter-core communication; and use the real-time operating system to convert the management commands not constructed according to the protocol format into management commands constructed according to the protocol format.

[0167] In one implementation, the non-real-time operating system and the real-time operating system share a target memory area in a first core or a second core; accordingly, the non-real-time operating system sends management commands not constructed according to the protocol format to the real-time operating system via inter-core communication, including: using the non-real-time operating system to write the management commands not constructed according to the protocol format into the target memory area and using inter-core interrupts to notify the real-time operating system; and using the real-time operating system to read the management commands not constructed according to the protocol format from the target memory area.

[0168] In one embodiment, at least one accelerator card is connected to the host via a preset communication protocol; correspondingly, it also includes a first receiving module, configured to receive accelerator card management instructions sent by the host via the preset communication protocol.

[0169] In one implementation, it further includes a second receiving module configured to receive response data returned by at least one accelerator card in response to a management command.

[0170] The working process of each module and unit in this embodiment can be referred to the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0171] As can be seen, in this embodiment, the baseboard management controller constructs corresponding management commands in the same target protocol format to manage at least one accelerator card, which can realize unified management of multiple types of accelerator cards. For the same accelerator card, the constructed management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands. This enables more comprehensive information management of the accelerator card, which is beneficial to the stable operation of the accelerator card.

[0172] The following describes an electronic device provided by an embodiment of this application. The electronic device described below can be referred to in conjunction with other embodiments described herein.

[0173] This application discloses an electronic device, including:

[0174] Memory is set up to store computer programs;

[0175] The processor is configured to execute a computer program to implement the methods disclosed in any of the above embodiments.

[0176] In this embodiment, when the processor executes the computer program stored in the memory, it can perform the following steps: load the target bus driver and the target protocol driver using the operating system deployed on the core of the baseboard management controller; when at least one accelerator card is detected, construct management commands for at least one accelerator card according to the protocol format of the target protocol; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands; and send the management commands to at least one accelerator card through the target bus.

[0177] In this embodiment, when the processor executes the computer program stored in the memory, it can perform the following steps: after the baseboard management controller is powered on, start the real-time operating system deployed on the first core of the baseboard management controller; use the started real-time operating system to load the driver of the target bus and the driver of the target protocol.

[0178] In this embodiment, when the processor executes the computer program stored in the memory, it can perform the following steps: determine the command field according to the protocol format; the command field includes at least one of the following: data integrity check bit, message type flag bit, accelerator card identity flag bit, command code, total number of data packets flag bit, number of data packets flag bit, return data length, data payload, and check bit; construct static information class commands, dynamic information class commands, diagnostic information class commands, and firmware maintenance class commands based on the command field.

[0179] In this embodiment, when the processor executes the computer program stored in the memory, it can perform the following steps: determine that the message type flag bit in the command field is the first flag bit, and determine that different commands in the static information class command correspond to different command codes.

[0180] In this embodiment, when the processor executes the computer program stored in the memory, it can perform the following steps: determine that the message type flag bit in the command field is the second flag bit, and determine that different commands in the dynamic information class command correspond to different command codes.

[0181] In this embodiment, when the processor executes the computer program stored in the memory, it can perform the following steps: determine that the message type flag bit in the command field is the third flag bit, and determine that different commands in the diagnostic information class commands correspond to different command codes.

[0182] In this embodiment, when the processor executes the computer program stored in the memory, it can perform the following steps: determine that the message type flag bit in the command field is the fourth flag bit, and determine that different commands in the firmware upgrade command correspond to different command codes.

[0183] In this embodiment, when the processor executes the computer program stored in the memory, it can perform the following steps: after the baseboard management controller is powered on, start the non-real-time operating system deployed on the second core of the baseboard management controller; use the started non-real-time operating system to load the driver of the target bus and the driver of the target protocol.

[0184] In this embodiment, when the processor executes the computer program stored in the memory, it can perform the following steps: using a non-real-time operating system to send management commands that are not constructed according to the protocol format to the real-time operating system via inter-core communication; and using the real-time operating system to convert the management commands that are not constructed according to the protocol format into management commands constructed according to the protocol format.

[0185] In this embodiment, when the processor executes the computer program stored in the memory, it can perform the following steps: using a non-real-time operating system to write management commands that are not constructed according to the protocol format into the target memory area, and using inter-core interrupts to notify the real-time operating system; using the real-time operating system to read the management commands that are not constructed according to the protocol format from the target memory area.

[0186] In some embodiments, this application also provides an electronic device. This electronic device can be either a server as shown in FIG8 or a terminal as shown in FIG9. FIG8 and FIG9 are both structural diagrams of an electronic device according to an exemplary embodiment, and the content in the figures should not be considered as any limitation on the scope of use of this application.

[0187] Figure 8 is a schematic diagram of a server provided in an embodiment of this application. The server may include: at least one processor, at least one memory, a power supply, a communication interface, an input / output interface, and a communication bus. The memory is configured to store a computer program, which is loaded and executed by the processor to implement the relevant steps in the accelerator card management disclosed in any of the foregoing embodiments.

[0188] In this embodiment, the power supply is configured to provide operating voltage for each hardware device on the server; the communication interface can create a data transmission channel between the server and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not limited here; the input / output interface is used to acquire external input data or output data to the outside world, and its interface type can be selected according to application needs, and is not limited here.

[0189] In addition, the memory, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored on it include operating system, computer programs and data, etc., and the storage method can be temporary storage or permanent storage.

[0190] The operating system is used to manage and control the various hardware devices and computer programs on the server, enabling the processor to perform operations and processes on the data in the memory. It can be Windows Server, Netware, Unix, Linux, etc. The computer programs, in addition to those capable of performing the accelerator card management method disclosed in any of the foregoing embodiments, may also include computer programs capable of performing other specific tasks. The data may include application update information and application developer information.

[0191] Figure 9 is a schematic diagram of the structure of a terminal provided in an embodiment of this application. The terminal may include, but is not limited to, smartphones, tablets, laptops, or desktop computers.

[0192] Typically, the terminal in this embodiment includes a processor and a memory.

[0193] The processor may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor can be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA, and PLA (Programmable Logic Array). The processor may also include a main processor and coprocessors. The main processor, also known as a CPU (Central Processing Unit), is configured to process data in the wake-up state; the coprocessor is a low-power processor configured to process data in the standby state. In some embodiments, the processor may integrate a GPU, which is configured to handle the rendering and drawing of content required for display. In some embodiments, the processor may also include an AI (Artificial Intelligence) processor, configured to handle computational operations related to machine learning.

[0194] The memory may include one or more computer non-volatile storage media, which may be non-transitory. The memory may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory is at least configured to store the following computer program, which, after being loaded and executed by the processor, is capable of implementing the relevant steps in the accelerator card management method executed on the terminal side as disclosed in any of the foregoing embodiments. Furthermore, the resources stored in the memory may also include operating systems and data, and the storage method may be temporary or permanent storage. The operating system may include Windows, Unix, Linux, etc. The data may include, but is not limited to, application update information.

[0195] In some embodiments, the terminal may further include a display screen, an input / output interface, a communication interface, a sensor, a power supply, and a communication bus.

[0196] Those skilled in the art will understand that the structure shown in Figure 9 does not constitute a limitation on the terminal and may include more or fewer components than shown.

[0197] The following describes a non-volatile readable storage medium provided in an embodiment of this application. The non-volatile readable storage medium described below can be referred to in conjunction with other embodiments described herein.

[0198] A non-volatile readable storage medium is configured to store a computer program, wherein the computer program, when executed by a processor, implements the accelerator card management method disclosed in the foregoing embodiments. The non-volatile readable storage medium is a computer-readable non-volatile storage medium that serves as a carrier for resource storage. It can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored thereon include an operating system, computer programs, and data, and the storage method can be temporary or permanent storage.

[0199] The following describes a computer program product provided by an embodiment of this application. The computer program product described below can be referred to in conjunction with other embodiments described herein.

[0200] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the aforementioned disclosed accelerator card management method.

[0201] The following describes an accelerator card management system provided by an embodiment of this application. The accelerator card management system described below can be referred to in conjunction with other embodiments described herein.

[0202] This application discloses an accelerator card management system, including: at least one accelerator card and a baseboard management controller; the baseboard management controller is connected to at least one accelerator card via a target bus.

[0203] The baseboard management controller is configured to: load the target bus driver and the target protocol driver using the operating system deployed on its core; when at least one accelerator card is detected, construct management commands for at least one accelerator card according to the protocol format of the target protocol; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands; and send the management commands to at least one accelerator card via the target bus.

[0204] In one embodiment, the accelerator card management system further includes: a host; at least one accelerator card is connected to the host via a preset communication protocol; the host is configured to: send computing tasks to at least one accelerator card via the preset communication protocol; and send accelerator card management instructions to the baseboard management controller via the preset communication protocol.

[0205] In one embodiment, the baseboard management controller includes at least two cores; a real-time operating system is deployed on the first core, and a non-real-time operating system is deployed on the second core; the non-real-time operating system and the real-time operating system establish inter-core communication, and the non-real-time operating system communicates with at least one accelerator card through the inter-core communication with the real-time operating system; or the non-real-time operating system and the real-time operating system communicate independently with at least one accelerator card.

[0206] The working process of each device in this embodiment can be referred to the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0207] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0208] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of non-volatile readable storage medium known in the art.

[0209] This document uses optional embodiments to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for managing accelerator cards, characterized in that, It is applied to a baseboard management controller, which is connected to at least one accelerator card via a target bus; The method includes: The target bus driver and the target protocol driver are loaded using the operating system deployed on the core of the baseboard management controller. If the at least one accelerator card is detected, management commands are constructed for the at least one accelerator card according to the protocol format of the target protocol; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands; The management command is sent to the at least one accelerator card via the target bus.

2. The method according to claim 1, characterized in that, Build management commands for the at least one accelerator card according to the protocol format of the target protocol, including: The command fields are determined according to the protocol format; the command fields include: a message type flag and a command code; The static information class command, the dynamic information class command, the diagnostic information class command, and the firmware maintenance class command are constructed based on the command field; wherein, the message type flag bit corresponding to different types of management commands is different, and different commands in the same type of management command correspond to different command codes.

3. The method according to claim 2, characterized in that, The static information class commands include at least one of the following: accelerator card hardware version query command, accelerator card manufacturer number query command, accelerator card product number query command, accelerator card product serial number query command, accelerator card manufacturing time query command, and accelerator card firmware version query command; Accordingly, the message type flag bit in the command field is determined to be the first flag bit, and different commands in the static information class commands correspond to different command codes; Accordingly, upon scanning the at least one accelerator card and / or detecting a static information query instruction, the static information class command is constructed for the at least one accelerator card according to the protocol format.

4. The method according to claim 2, characterized in that, The dynamic information commands include at least one of the following: accelerator card temperature query command, accelerator card power consumption query command, accelerator card voltage query command, accelerator card-host link negotiation bandwidth query command, accelerator card-host link negotiation rate query command, and accelerator card processor utilization query command. Accordingly, the message type flag in the command field is determined to be the second flag, and different commands in the dynamic information class commands correspond to different command codes; Accordingly, when it is detected that the at least one accelerator card is in operation, the dynamic information class command is periodically constructed for the at least one accelerator card in accordance with the protocol format.

5. The method according to claim 2, characterized in that, The diagnostic information commands include at least one of the following: accelerator card health status query command, accelerator card return review status query command, accelerator card high-speed serial computer expansion bus error count query command, accelerator card memory error count query command, accelerator card peripheral error count query command, accelerator card correction code error count query command, uncorrectable error status register query command, uncorrectable error mask register query command, uncorrectable error level register query command, correctable error status register query command, correctable error mask register query command, correctable error level register query command, advanced error report control register query command, advanced error report header log register query command, and advanced error report transaction layer packet log register query command; Accordingly, the message type flag in the command field is determined to be the third flag, and different commands in the diagnostic information class commands correspond to different command codes; Accordingly, upon detecting a diagnostic command from the at least one accelerator card, the diagnostic information class command is periodically constructed for the at least one accelerator card according to the protocol format.

6. The method according to claim 2, characterized in that, The firmware upgrade commands include: accelerator card firmware protection status query command, accelerator card firmware protection status setting command, accelerator card firmware upgrade command, accelerator card system reset command, and accelerator card power on / off command; Accordingly, the message type flag in the command field is determined to be the fourth flag, and different commands in the firmware upgrade command class correspond to different command codes; Accordingly, upon detecting a firmware upgrade instruction for the at least one accelerator card, a firmware upgrade class command is constructed for the at least one accelerator card according to the protocol format.

7. The method according to claim 2, characterized in that, The command fields also include: data integrity check bit, accelerator card identification bit, total number of data packets flag bit, number of data packets flag bit, return data length, data payload, and check bit.

8. The method according to claim 1, characterized in that, The target bus driver and target protocol driver are loaded using the operating system deployed on the core of the baseboard management controller, including: After the baseboard management controller is powered on, the real-time operating system deployed on the first core of the baseboard management controller is started. The driver for the target bus and the driver for the target protocol are loaded using the real-time operating system after startup.

9. The method according to claim 1, characterized in that, The target bus driver and target protocol driver are loaded using the operating system deployed on the core of the baseboard management controller, including: After the baseboard management controller is powered on, the non-real-time operating system deployed on the second core of the baseboard management controller is started. The driver for the target bus and the driver for the target protocol are loaded using the non-real-time operating system after startup.

10. The method according to claim 9, characterized in that, A real-time operating system is deployed on the first core of the baseboard management controller, and the non-real-time operating system and the real-time operating system establish inter-core communication. Accordingly, management commands are constructed for the at least one accelerator card according to the protocol format of the target protocol, including: The non-real-time operating system is used to send management commands, which are not constructed according to the protocol format, to the real-time operating system via inter-core communication. The real-time operating system is used to convert management commands that are not constructed according to the protocol format into management commands constructed according to the protocol format.

11. The method according to claim 10, characterized in that, The non-real-time operating system and the real-time operating system share the target memory area in the first core or the second core; Accordingly, using the non-real-time operating system to send management commands not constructed according to the protocol format to the real-time operating system via the inter-core communication includes: The non-real-time operating system is used to write management commands that are not constructed according to the protocol format into the target memory area, and the real-time operating system is notified by inter-core interrupts. The real-time operating system is used to read management commands from the target memory area that are not constructed according to the protocol format.

12. The method according to any one of claims 1 to 11, characterized in that, The at least one accelerator card is connected to the host via a preset communication protocol; Correspondingly, it also includes: The system receives accelerator card management instructions sent by the host via the preset communication protocol.

13. The method according to any one of claims 1 to 11, characterized in that, Also includes: Receive response data returned by the at least one accelerator card in response to the management command.

14. An accelerator card management device, characterized in that, It is applied to a baseboard management controller, which is connected to at least one accelerator card via a target bus; The device includes: The system control module is configured to load the driver for the target bus and the driver for the target protocol using the operating system deployed on the core of the baseboard management controller; The command construction module is configured to construct management commands for the at least one accelerator card according to the protocol format of the target protocol when the at least one accelerator card is detected; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands; The command sending module is configured to send the management command to the at least one accelerator card via the target bus.

15. An electronic device, characterized in that, include: The memory is configured to store computer programs; A processor is configured to execute the computer program to implement the method as described in any one of claims 1 to 13.

16. A non-volatile readable storage medium, characterized in that, It is configured to store a computer program, wherein the computer program, when executed by a processor, implements the method as described in any one of claims 1 to 13.

17. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the method as described in any one of claims 1 to 13.

18. An accelerator card management system, characterized in that, include: Baseboard management controller and at least one accelerator card; The baseboard management controller is connected to the at least one accelerator card via a target bus; The baseboard management controller is configured to: load the driver of the target bus and the driver of the target protocol using the operating system deployed on its core; when the at least one accelerator card is detected, construct management commands for the at least one accelerator card according to the protocol format of the target protocol; the management commands include at least one of the following: static information commands, dynamic information commands, diagnostic information commands, and firmware maintenance commands; and send the management commands to the at least one accelerator card through the target bus.

19. The system according to claim 18, characterized in that, The accelerator card management system also includes: a host; The at least one accelerator card is connected to the host via a preset communication protocol; The host is configured to: send computing tasks to the at least one accelerator card via the preset communication protocol; and send accelerator card management instructions to the baseboard management controller via the preset communication protocol.

20. The system according to claim 18, characterized in that, The baseboard management controller includes at least two cores; a real-time operating system is deployed on the first core, and a non-real-time operating system is deployed on the second core. The non-real-time operating system and the real-time operating system establish inter-core communication. The non-real-time operating system communicates with the at least one accelerator card through inter-core communication with the real-time operating system; or the non-real-time operating system and the real-time operating system communicate independently with the at least one accelerator card.

Images