A server extension component asset information statistics method, device, equipment and medium

Abstract

The application discloses a server expansion component asset information statistical method and device, equipment and medium, and relates to the technical field of information processing. The method comprises the following steps: receiving each data subpacket sent by a BIOS; each data subpacket is obtained by grouping hardware identification data of a server expansion device by the BIOS to obtain multiple groups of sub-identification data, and then encapsulating each group of sub-identification data and a corresponding sub-identification data packet number; analyzing each data subpacket to obtain sub-identification data in each data subpacket and a corresponding sub-identification data packet number; splicing multiple groups of sub-identification data based on the sub-identification data packet number to obtain hardware identification data of the server expansion device; extracting the hardware identification data of the server expansion device to obtain multiple groups of target fields; and performing hierarchical matching on each group of target fields and a resource mapping table to obtain asset information corresponding to the server expansion device. The method can improve the accuracy of expansion component asset information statistics.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to a method, apparatus, device and medium for statistical analysis of asset information of server expansion components. Background Technology

[0002] Servers are equipped with various expansion components such as network cards, GPUs (Graphics Processing Units), and RAID (Redundant Array of Independent Disks) cards. Maintenance personnel need to be familiar with the model numbers of these components for asset management and troubleshooting. In the industry, the BIOS (Basic Input / Output System) collects hardware data upon startup, and the BMC (Baseboard Management Controller) compiles the asset list. The two work together to complete information statistics.

[0003] Traditional solutions rely on firmware to map component assets, requiring simultaneous modifications and reflashing of the firmware code for any hardware changes. Furthermore, the lack of effective integrity guarantees during data transmission makes information transfer prone to errors. The fixed and unscalable methods for information querying and matching also hinder adaptability to complex and ever-changing environments. Any deviation or delay in any of these stages—firmware, transmission, or matching—will affect the final hardware identification result.

[0004] Therefore, traditional solutions suffer from poor accuracy in statistical analysis of extended component asset information. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for statistical analysis of server expansion component asset information, which can improve the accuracy of expansion component asset information analysis.

[0006] To achieve the above objectives, this application adopts the following technical solution: Firstly, this application provides a method for statistical analysis of server expansion component asset information, including: Receive data sub-packets sent by the Basic Input / Output System (BIOS); each data sub-packet is obtained by the BIOS grouping the hardware identification data of the server expansion device into multiple groups of sub-identification data, and then encapsulating each group of sub-identification data with the corresponding packet sequence number of each group of sub-identification data. Each data sub-packet is parsed to obtain the sub-identifier data and the corresponding sub-packet sequence number in each data sub-packet; Based on the packet sequence number, multiple sets of sub-identifier data are concatenated to obtain the hardware identification data of the server extension device. Extract the hardware identification data of the server expansion device to obtain multiple sets of target fields; Each set of target fields is matched hierarchically with a preset resource mapping table to obtain the asset information corresponding to the server extension device.

[0007] In some possible implementations, after receiving the data sub-packets sent by the Basic Input / Output System BIOS, the following is also included: Extract the packet sequence number and target checksum from each data sub-packet; based on the packet sequence number, perform deduplication on each data sub-packet to obtain deduplicated data sub-packets; based on the target checksum, verify each deduplicated data sub-packet to identify data sub-packets that fail verification; discard the data sub-packets that fail verification and send a retransmission request for the data sub-packets that fail verification to the BIOS.

[0008] In some possible implementations, after receiving the data sub-packets sent by the Basic Input / Output System BIOS, the following is also included: Extract the sequence number from each data sub-packet; sort the data sub-packets based on the sequence number to determine the missing sequence number; for the missing sequence number, send a retransmission request to the BIOS for the data sub-packet with the missing sequence number.

[0009] In some possible implementations, each set of target fields is hierarchically matched with a pre-defined resource mapping table to obtain the asset information corresponding to the server extension device, including: For each set of target fields, the target fields are used as the first search key to perform a match in the first matching table, resulting in a first matching result. If the first matching result is not empty, the asset information corresponding to the server extension device is determined based on the first matching result. If the first matching result is empty, the first identifier, second identifier, and first code in the target fields are used as the second search key to perform a match in the second matching table, resulting in a second matching result. If the second matching result is not empty, the asset information corresponding to the server extension device is determined based on the second matching result. If the second matching result is empty, the first identifier and second identifier in the target fields are used as the third search key to perform a match in the third matching table, resulting in a third matching result. If the third matching result is not empty, the asset information corresponding to the server extension device is determined based on the third matching result. If the third matching result is empty, the device is determined to be an unknown device.

[0010] Among the possible implementations are: Receive the component information configuration table; parse each record in the component information configuration table to determine the first identifier, second identifier, first code, second code, and corresponding asset information field in each record; construct a first matching table based on the first identifier, second identifier, first code, second code, and corresponding asset information field; construct a second matching table based on the first identifier, second identifier, first code, and corresponding asset information field; construct a third matching table based on the first identifier, second identifier, and corresponding asset information field; and construct a preset resource mapping table based on the first, second, and third matching tables.

[0011] Among the possible implementations are: The BIOS acquires the hardware identification data of the server expansion device; the BIOS groups the hardware identification data to obtain multiple sets of sub-identification data; the BIOS encapsulates each set of sub-identification data with its corresponding packet sequence number to obtain a data sub-packet corresponding to each set of sub-identification data; the BIOS transmits each data sub-packet to the Baseboard Management Controller (BMC) so that the BMC can parse each data sub-packet to obtain the corresponding sub-identification data and packet sequence number; the BMC uses the packet sequence number to concatenate multiple sets of sub-identification data to obtain the hardware identification data of the server expansion device; the hardware identification data of the server expansion device is then extracted to obtain multiple sets of target fields; each set of target fields is then matched hierarchically with a preset resource mapping table to obtain the asset information corresponding to the server expansion device.

[0012] In some possible implementations, after the BIOS transmits the data sub-packets to the Baseboard Management Controller (BMC), it also includes: Receive retransmission requests from the BMC; retrieve the sub-identifier data corresponding to the packet sequence number in the retransmission request; repackage the sub-identifier data corresponding to the packet sequence number in the retransmission request to obtain a new data sub-packet; send the new data sub-packet to the BMC.

[0013] Secondly, this application provides a server expansion component asset information statistics device, comprising: The receiving module is used to receive the data sub-packets sent by the Basic Input / Output System (BIOS). Each data sub-packet is obtained by the BIOS grouping the hardware identification data of the server expansion device into multiple groups of sub-identification data, and then encapsulating each group of sub-identification data with the corresponding packet sequence number. The parsing and processing module is used to parse each data sub-packet to obtain the sub-identifier data and the corresponding sub-packet sequence number in each data sub-packet; based on the sub-packet sequence number, multiple sets of sub-identifier data are concatenated to obtain the hardware identification data of the server expansion device; the hardware identification data of the server expansion device is extracted to obtain multiple sets of target fields; The asset matching module is used to perform hierarchical matching of each set of target fields with a preset resource mapping table to obtain the asset information corresponding to the server extension device.

[0014] Thirdly, this application provides a computing device, including a memory and a processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of the first aspects.

[0015] Fourthly, this application provides a computer-readable storage medium for storing a computer program for performing the method as described in any one of the first aspects.

[0016] Fifthly, this application provides a computer program product comprising one or more computer instructions, wherein when the computer instructions are executed by a computer, the computer performs the method as described in any one of the first aspects.

[0017] As can be seen from the above technical solution, this application has at least the following beneficial effects: In this application, the BMC receives data sub-packets sent by the BIOS. Each data sub-packet is obtained by the BIOS grouping the hardware identification data of the server expansion device and encapsulating it with a sub-packet sequence number. The BMC parses each data sub-packet to obtain the sub-identification data and the corresponding sub-packet sequence number. Based on the sub-packet sequence number, multiple groups of sub-identification data are concatenated to restore the complete hardware identification data. The hardware identification data is extracted to obtain multiple sets of target fields. Finally, each set of target fields is hierarchically matched with a preset resource mapping table to obtain the asset information corresponding to the server expansion device.

[0018] This solution introduces packet sequence numbers when the BIOS sends hardware identification data. This allows the BMC to sequentially reassemble multiple sets of sub-identification data according to the sequence numbers at the receiving end, restoring the complete hardware identification data. This ensures that even if packets are out of order or partially lost during cross-firmware transmission from the BIOS to the BMC, the BMC can still accurately reconstruct the complete data based on the packet sequence numbers, avoiding hardware identification data corruption or incompleteness caused by unreliable transmission. Furthermore, by introducing hierarchical matching, it automatically downgrades to partial or wildcard matching when exact matching fails, giving the device identification process fault tolerance and adaptability. Ultimately, this improves the accuracy of extended component asset information statistics.

[0019] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0020] Figure 1 An application environment diagram for a server expansion component asset information statistics method provided in this application embodiment; Figure 2 A flowchart illustrating a method for statistical analysis of server expansion component asset information provided in this application embodiment; Figure 3 A structural diagram of a server expansion component asset information statistics device provided in this application embodiment; Figure 4 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0021] The terms "first," "second," and "third," etc., used in this application specification and accompanying drawings are used to distinguish different objects, not to limit a specific order.

[0022] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0023] The BIOS, as the first firmware to run after the server powers on, is responsible for enumerating the PCIe (Peripheral Component Interconnect Express) bus during the POST (Power-On Self-Test) phase. It obtains the hardware identification data of the devices by reading fields such as VID (Vendor ID), DID (Device ID), SubVID (Subsystem Vendor ID), SubDID (Subsystem Device ID), and BDF (Bus / Device / Function) from the server's extended device configuration space. The BMC, a dedicated microcontroller embedded in the server motherboard, is responsible for organizing asset information.

[0024] The BIOS and BMC exchange data via the KCS (Keyboard Controller Style) channel. The KCS channel is one of the commonly used interfaces for communication between the BMC and BIOS in servers. Its single transmission capacity is limited; when the total size of the hardware identification data exceeds the capacity of a single packet, the data needs to be split into multiple data packets and sent separately. At the receiving end, the BMC needs to reassemble the received data packets into complete hardware identification data. However, due to the transmission characteristics of the KCS channel, issues such as inconsistent packet arrival order with the sending order, partial data packet loss, and the BIOS retransmitting due to timeouts, causing the BMC to receive duplicate data packets, may occur during packet splitting. These issues can all affect the integrity of the hardware identification data finally assembled by the BMC.

[0025] The hardware identification data read by the BIOS from the PCIe configuration space is an inherent attribute of the device hardware. However, when performing asset management and troubleshooting, maintenance personnel focus on business-level asset information such as device type, model name, manufacturer name, and material code. To convert hardware identification data into asset information, it is usually necessary to establish a mapping relationship between hardware identification parameters and asset information, and complete the conversion by querying this mapping relationship. Traditional mapping relationship maintenance methods often write the resource mapping table directly into the BIOS or BMC firmware. When a component model is added, the supplier is changed, or the material code is adjusted, the firmware code needs to be modified and re-flashed, resulting in long maintenance cycles and poor flexibility. The resource mapping table is usually stored in the firmware code as a linear list or array structure. The matching process requires traversing each record in the resource mapping table. When the number of devices and mapping records is large, the matching time increases linearly with the number of records, affecting the timeliness of asset information generation.

[0026] In view of this, embodiments of this application provide a method for statistical analysis of server expansion component asset information. To make the technical solution of this application clearer and easier to understand, the application scenarios of the technical solution of this application are described below with reference to the accompanying drawings. Figure 1 As shown, this figure is an application environment diagram provided by an embodiment of this application.

[0027] In this application environment, after the server powers on, the BIOS performs POST (Power-On Self-Service), reading VID, DID, SubVID, SubDID, and BDF from the PCIe configuration space of each expansion device. This data is then combined into hardware identification data and packetized. Each group of sub-identifier data and its sequence number are encapsulated into a data sub-packet, which is sent to the BMC (Browser Control Center) via the KCS (Knowledge, Control, and Controller) channel. The BMC performs verification, deduplication, and retransmission processing on each data sub-packet. After collecting all sub-packets, it reassembles them according to their sequence numbers to restore the complete hardware identification data. Multiple target fields are extracted from this data and matched hierarchically with a pre-defined resource mapping table to obtain the asset information corresponding to each expansion device.

[0028] To make the technical solution of this application clearer and easier to understand, the following describes a method for statistical analysis of server expansion component asset information, using the BMC as the executing entity, in conjunction with the above application scenarios. For example... Figure 2 As shown in the figure, this is a flowchart illustrating a method for statistically analyzing server expansion component asset information according to an embodiment of this application. The method includes: S201: Receive data sub-packets sent by the BIOS.

[0029] Each data sub-packet is obtained by the BIOS grouping the hardware identification data of the server expansion device into multiple groups of sub-identification data, and then encapsulating each group of sub-identification data with its corresponding sub-packet sequence number. The sub-packet sequence number is a number assigned by the BIOS to each group of sub-identification data when grouping the hardware identification data, used to identify the sequential position of that group of sub-identification data in all the sub-identification data, starting from 0.

[0030] The BMC receives data sub-packets sent by the BIOS through the KCS channel. During the POST phase, the BIOS scans the bus number, device number, and function number of the server expansion devices, and reads fields such as VID, DID, SubVID, SubDID, and BDF from the PCIe configuration space of the server expansion devices, combining these fields into hardware identification data. Because the single transmission capacity of the KCS channel is limited, and the total size of the hardware identification data exceeds the single packet capacity when there are many server expansion devices, the BIOS needs to group the hardware identification data. The BIOS divides the hardware identification data into multiple groups of sub-identification data and assigns a packet sequence number to each group (which contains one or more PCIe device records) to identify the sequential position of each group of data within the total data. The BIOS encapsulates each set of sub-identifier data, along with the corresponding packet sequence number, total number of packets, boot cycle identifier BootID, and the target checksum calculated from the content of that data sub-packet, into a data sub-packet. The encapsulation format is as follows: a fixed magic number of 4 bytes at offset 0x00, a protocol version number of 2 bytes at offset 0x04, the current packet sequence number of 2 bytes at offset 0x06, the total number of packets of 2 bytes at offset 0x08, the boot cycle identifier BootID of 4 bytes at offset 0x0A, the number of records in this packet of 2 bytes at offset 0x0E (the number of PCIe device record entries carried in the data sub-packet), the payload length of 4 bytes at offset 0x10, the target checksum of 4 bytes at offset 0x14, and a variable-length PCIe device record array (i.e., sub-identifier data) starting at offset 0x18. The data packet is identified by a fixed magic number, indicating it's a PCIe device data packet sent from the BIOS to the BMC. The protocol version number supports forward compatibility parsing of data packets from different BIOS versions by the BMC. The boot cycle identifier (BootID) identifies the current boot cycle; the BMC uses the BootID to identify and discard old data packets from the previous boot cycle. The target checksum is a checksum obtained by the BIOS after performing cyclic redundancy check on the data sub-packet. It's used by the BMC to verify whether a bit error occurred during transmission. For example, the target checksum is a CRC32 (Cyclic Redundancy Check 32-bit) checksum. The BIOS encapsulates each group of sub-identifier data sequentially according to the above format, and after obtaining each data sub-packet, sends it to the BMC packet by packet through the KCS channel.

[0031] S202. Parse each data sub-packet to obtain the sub-identifier data and the corresponding sub-packet sequence number in each data sub-packet.

[0032] After parsing each data sub-packet, the following is also included: Extract the packet sequence number and target checksum from each data sub-packet; based on the packet sequence number, perform deduplication on each data sub-packet to obtain deduplicated data sub-packets; based on the target checksum, verify each deduplicated data sub-packet to identify data sub-packets that fail verification; discard the data sub-packets that fail verification and send a retransmission request for the data sub-packets that fail verification to the BIOS.

[0033] A retransmission request is a control command sent by the BMC to the BIOS when it detects a data sub-packet loss or verification failure, requesting the retransmission of the data sub-packet corresponding to the specified sub-packet sequence number.

[0034] BMC maintains a sliding window packet assembly state machine, which includes the following state variables: a bitmap called received_bitmap that records which packet sequence numbers have been received, a state start cycle identifier boot_id, and the total number of packets total. Upon receiving each data sub-packet, the BMC first extracts the packet header fields, reading the packet sequence number, target checksum, fixed magic number, and boot ID. It then checks if the fixed magic number in the header matches the protocol's preset magic number constant (e.g., 0x42494F50). If the fixed magic number doesn't match, the data sub-packet is discarded. If the fixed magic number matches, the boot ID is compared with the boot_id recorded in the current state machine. If the sliding window packet assembly state machine has already been initialized, and the received boot ID doesn't match the state machine's boot_id, the data sub-packet is determined to be a residual delayed message from a historical boot cycle. The BMC discards the data sub-packet without modifying the internal state machine variables or resetting the sliding window. The sliding window packet assembly state machine is used. If the sliding window packet assembly state machine has not been initialized, and the received BootID is a valid identifier, the boot_id of the state machine is updated to the newly received BootID, the received_bitmap is initialized, and the memory storage location corresponding to the sub-packet is allocated. If the received BootID is consistent with the boot_id, the BMC checks whether the sub-packet sequence number has been marked as received in the received_bitmap. If it has been marked, it means that the sub-packet is a duplicate packet, and the BMC discards the duplicate packet without further processing. If the sub-packet sequence number has not been marked, the BMC stores the data sub-packet corresponding to the sub-packet sequence number in memory at the storage location corresponding to the sub-packet sequence number, and marks the bit corresponding to the sub-packet sequence number in the received_bitmap.

[0035] For each data sub-packet after deduplication, the BMC extracts its payload portion and calculates a local checksum for all bytes of the payload using the CRC32 algorithm. This local checksum is compared to the target checksum extracted from the packet header. If they match, the checksum passes; otherwise, the checksum fails, indicating a bit error occurred during transmission. The BMC discards the failed data sub-packet from memory and sends a retransmission request to the BIOS, carrying the sequence number of the failed sub-packet. Upon receiving the retransmission request, the BIOS retrieves the corresponding sub-identifier data based on the sequence number, repackages the sub-identifier data to obtain a new data sub-packet, and retransmits the new data sub-packet to the BMC.

[0036] After parsing each data sub-packet, the integrity of the data sub-packets can be checked based on the packet sequence number. Specifically, this can include: Extract the sequence number from each data sub-packet; sort the data sub-packets based on the sequence number to determine the missing sequence number; for the missing sequence number, send a retransmission request to the BIOS for the data sub-packet with the missing sequence number.

[0037] Specifically, the BMC extracts the packet sequence number and total number of packets from each data sub-packet. It sorts the received and verified data sub-packets by their sequence numbers in ascending order, and then checks if any sequence numbers are missing between 0 and the total number of packets minus 1. If missing sequence numbers are found, the BMC sends a retransmission request to the BIOS for each missing sequence number, requesting the BIOS to retransmit the data sub-packet corresponding to that missing sequence number. The BMC sets a timeout window T (e.g., 100ms) and waits for missing data sub-packets within this window. If the data sub-packets corresponding to all missing sequence numbers are not received within the timeout window, the BMC sends another retransmission request to the BIOS for the remaining missing sequence numbers, until all data sub-packets corresponding to all sequence numbers are received or the maximum number of retransmissions (e.g., 5 times) is exceeded. Note that the KCS is the low-speed channel between the server BIOS and BMC; T cannot be set too small, otherwise frequent retransmissions will occur; nor can it be set too large, slowing down the boot-up asset acquisition process.

[0038] The BMC reads information field by field from each data sub-packet according to the data sub-packet encapsulation format agreed upon between the BIOS and the BMC. The BMC reads 2 bytes of the current packet sequence number from offset 0x06 to obtain the corresponding packet sequence number for that data sub-packet. The BMC then reads the number of bytes specified by the payload length, starting from offset 0x18, to obtain the sub-identifier data within that data sub-packet. The BMC stores the parsed packet sequence number and the corresponding sub-identifier data.

[0039] S203. Based on the sub-packet sequence number, multiple sets of sub-identifier data are concatenated to obtain the hardware identification data of the server extended device.

[0040] BMC sorts all packet sequence numbers in ascending order, forming an ordered packet sequence. Each packet sequence number corresponds to a complete set of sub-identifier data. Following the ordered packet sequence, BMC sequentially reads the hardware identifier segment information stored within each set of sub-identifier data, and concatenates all segments byte-by-byte. The concatenation process does not alter the original byte order within each sub-identifier data segment. After all sub-identifier data is concatenated, it is merged to obtain complete and continuous hardware identifier data for the server expansion device. The BMC maintains the received packet sequence number bitmap associated with the sliding window packet assembly state machine. Before the splicing operation is executed, all the marker bits in the bitmap are read to confirm that the sequence numbers corresponding to all total packets have been received, verified, deduplicated, and retained, and that there are no missing packet sequence numbers. Then, the splicing of multiple sets of sub-identifier data is started. If there are unset packet sequence number marker bits in the bitmap, the splicing operation is paused, and a retransmission request corresponding to the missing packet sequence number is sent to the BIOS. This continues until the data sub-packets corresponding to all packet sequence numbers have been received and verified. Then, the complete splicing process is performed, and finally, the hardware identification data of the server expansion device is obtained.

[0041] S204. Extract the hardware identification data of the server expansion device to obtain multiple sets of target fields.

[0042] The hardware identification data of the server expansion devices is in the form of a continuous byte stream. Within this byte stream, the original hardware identification information for each server expansion device is stored in segments with fixed offsets. This original hardware identification information includes original identifiers such as VID, DID, SubVID, SubDID, and BDF. The BMC traverses the complete byte stream of the server expansion device's hardware identification data according to a preset fixed byte offset rule, and splits the complete byte stream by single server expansion devices, resulting in independent hardware original data segments for each device. For each independent hardware original data segment, VID, DID, SubVID, and SubDID are extracted according to preset fields. The extracted VID, DID, SubVID, and SubDID identifiers are combined into a single target field. This process of splitting the complete byte stream, extracting fields, and combining fields is repeated until the entire byte stream of the server expansion device's hardware identification data has been traversed, at which point multiple single target fields are generated.

[0043] The preset fields are pre-agreed internal field definitions and byte offsets of the parsing protocol. BIOS packaged device records must follow these offsets. When parsing, BMC truncates the data according to these offsets, such as VID at offset 0-1, DID at offset 2-3, SubVID at offset 4-5, and SubDID at offset 6-7. After truncating a single target field, BMC performs standardization processing, such as removing hexadecimal character prefixes, unifying character case, and padding with four characters. Finally, the standardized identifier content is stored in the corresponding target field group.

[0044] S205. Perform hierarchical matching of each set of target fields with the preset resource mapping table to obtain the asset information corresponding to the server extension device.

[0045] The resource mapping table is an external configuration file that stores the mapping relationship between all server expansion component identification parameters and asset information. Server expansion component identification parameters are fields read from the PCIe configuration space of the server expansion device to uniquely identify the hardware identity of that device, including VID, DID, SubVID, and SubDID. Asset information consists of descriptive fields required by the server expansion device at the business management level, including device type, device model name, manufacturer name, material code, and component number. The resource mapping table exists as an independent configuration table, independent of the BIOS and BMC firmware. When adding component types or adjusting asset information is required, maintenance personnel can expand or update the resource mapping table by editing a CSV (Comma Separated Values) file and importing it into the BMC through the BMC's WebUI or Redfish interface, without requiring any modifications to the BIOS or BMC firmware. This ensures that the mapping relationship upon which asset information statistics depend has good scalability and maintainability. The independent configuration table can exist in xlsx (Office Open XML Spreadsheet Document) or CSV format.

[0046] The resource mapping table includes a first matching table, a second matching table, and a third matching table. The matching accuracy of the first matching table is higher than that of the second matching table, and the matching accuracy of the second matching table is higher than that of the third matching table. The first matching table is a hash index table constructed using the first identifier, second identifier, first code, and second code as the search key. The second matching table is a hash index table constructed using the first identifier, second identifier, and first code as the search key. The third matching table is a hash index table constructed using the first identifier and second identifier as the search key. The first identifier is a fixed identifier parameter within the target field used to identify the hardware chip manufacturer, corresponding to VID. The second identifier is a fixed identifier parameter within the target field used to identify the hardware chip model, corresponding to DID. The first code is a fixed code parameter within the target field used to identify the board integration manufacturer, corresponding to SubVID. The second code is a fixed code parameter within the target field used to identify the specific model of the board, corresponding to SubDID. The asset information field records information such as the model, material code, and specifications of server expansion components. Hierarchical matching is a sequential search operation that performs searches in the first matching table, the second matching table, and the third matching table in descending order of matching accuracy.

[0047] The process of constructing a resource mapping table can be as follows: Receive the component information configuration table, which is in xlsx file format (an xlsx file is essentially a zip compressed package). Each row of records corresponds to a server extended component model and includes the component's first identifier, second identifier, first code, second code, and corresponding asset information fields.

[0048] Each record in the component information configuration table is parsed to determine the first identifier, second identifier, first code, second code, and corresponding asset information field. For example, BMC uses an event-driven streaming parsing method to process the component information configuration table, but does not fully load the complete document object model of the component information configuration table. BMC decompresses the compressed package corresponding to the component information configuration table, but does not decompress all files at once. It only reads the form XML (Extensible Markup Language) file (i.e., the XML file corresponding to the sheet containing the component data rows in the xlsx file) that stores the component records, and reads the row node data inside the form XML line by line. When reading the first row of the form header node, BMC matches the text content of each column in the header with the internally pre-stored preset alias library to determine the column offset positions corresponding to the first identifier, second identifier, first code, second code, and asset information field, respectively. The preset alias library stores the corresponding possible column name descriptions for each internal standard field, such as the alias for the first identifier including VID. BMC traverses the form except for the header. For all data rows other than those specified, extract the first identifier, second identifier, first code, second code, and the asset information field bound to that row from each record according to the determined column offset. Perform standardization processing on the extracted first identifier, second identifier, first code, and second code, removing hexadecimal prefix characters, unifying letter case, and padding to four characters. After completing the parsing, field extraction, and standardization processing of all records in the component information configuration table, BMC directly releases all intermediate cached data corresponding to the form XML file from this parsing process, no longer retaining the form XML related document objects, thus reducing BMC's memory overhead.

[0049] Based on the first identifier, the second identifier, the first code, the second code, and the corresponding asset information fields, a first matching table is constructed. That is, BMC uses the standardized combination string of the first identifier, the second identifier, the first code, and the second code as the search key, and the corresponding asset information field as the value, and stores them in the hash storage space of the first matching table in the form of key-value pairs, thus completing the construction of the first matching table.

[0050] Based on the first identifier, the second identifier, the first code, and the corresponding asset information fields, a second matching table is constructed. Specifically, the standardized combination string of the first identifier, the second identifier, and the first code is used as the search key, and the corresponding asset information field is used as the value. The data is stored in the hash storage space of the second matching table in the form of key-value pairs, thus completing the construction of the second matching table.

[0051] Based on the first identifier, the second identifier, and the corresponding asset information fields, a third matching table is constructed. Specifically, the standardized combination of the first and second identifier strings is used as the search key, and the corresponding asset information fields are used as the values. These are stored in the hash storage space of the third matching table in the form of key-value pairs, thus completing the construction of the third matching table.

[0052] Based on the first, second, and third matching tables, a preset resource mapping table is constructed. Specifically, BMC encapsulates and stores the completed first, second, and third matching tables, combining them to form the preset resource mapping table. After the resource mapping table is constructed, BMC only retains the hash storage space for the first, second, and third matching tables, as well as the array of asset information fields, resident in memory.

[0053] The hierarchical matching process can be as follows: BMC iterates through each group of standardized target fields and performs the following continuous retrieval actions for each group of target fields. BMC extracts the first identifier, second identifier, first code, and second code from the current group of target fields, concatenates them to generate the first search key, inputs the first search key into the first matching table to perform a hash lookup operation, reads the asset information field bound to the first search key from the first matching table, and generates the first matching result. BMC determines whether a valid asset information field exists within the first matching result: if the first matching result is not empty, it directly extracts the asset information field carried by the first matching result, sets this asset information field as the asset information of the server extension device corresponding to this group of target fields, terminates the matching process for this group of target fields, and BMC reads the next group of target fields to begin a new round of matching.

[0054] If the first matching result is empty, BMC extracts the first identifier, second identifier, and first code from the target field of the current group, concatenates them to generate the second search key, inputs the second search key into the second matching table to perform a hash lookup operation, reads the asset information field bound to the second search key from the second matching table, and generates the second matching result. If the second matching result is not empty, the asset information field carried by the second matching result is directly extracted, and this asset information field is set as the asset information of the server extension device corresponding to the target field of this group. The matching process of the target field of this group terminates, and BMC reads the next group of target fields to start a new round of matching.

[0055] If the second matching result is empty, BMC extracts the first and second identifiers from the target field of the current group, concatenates them to generate the third search key, inputs the third search key into the third matching table to perform a hash lookup operation, reads the asset information field bound to the third search key from the third matching table, and generates the third matching result. If the third matching result is not empty, the asset information field carried by the third matching result is directly extracted, and this asset information field is set as the asset information of the server extension device corresponding to the target field of this group.

[0056] If the third matching result is empty, BMC marks the server extension device corresponding to the target field of the current group as an unknown device and synchronously records all identification parameters of the target field of this group. BMC repeats the above retrieval and judgment logic, processes all multiple groups of target fields in sequence, and completes the determination of all server extension device asset information.

[0057] During the retrieval process, if a single search key corresponds to multiple asset information fields, BMC retrieves the preset scoring rules and sequentially reads the slot matching parameters, machine type matching parameters, link bandwidth matching parameters, authentication status parameters, and conflict deduction parameters to calculate the score. The single asset information field with the highest score is selected as the final asset information. The score calculation process can be as follows:

[0058] in, As a score; This is a slot matching parameter, indicating whether the slot type recorded in the candidate asset information is consistent with the slot type actually plugged into the current server expansion device. If they are consistent, the value of this item is 1; otherwise, the value is 0. This is the weighting coefficient corresponding to the slot matching parameter, such as a value of 0.3; This is the device model matching parameter, indicating whether the compatible device model recorded in the candidate asset information matches the device model of the current server. If they match, the value of this item is 1; otherwise, the value is 0. The weighting coefficient corresponding to the model matching parameters, such as a value of 0.25; This is a link bandwidth matching parameter, indicating whether the link width requirement recorded in the candidate asset information is consistent with the link width actually negotiated by the current server expansion device. If they are consistent, the value of this item is 1; otherwise, the value is 0. The weighting coefficient corresponding to the link bandwidth matching parameter, such as a value of 0.2; This is an authentication status parameter, indicating whether the component corresponding to the candidate asset information has been authenticated. If it has been authenticated, the value of this item is 1; if it has not been authenticated, the value of this item is 0. This is the weighting coefficient corresponding to the authentication status parameter, such as a value of 0.15; This is a conflict deduction parameter, indicating whether there is a conflict between the current candidate asset information and the historical manual correction record. If there is a conflict, this item is set to 1; if there is no conflict, it is set to 0. This is the weighting coefficient corresponding to the conflict deduction parameter, such as a value of 0.1.

[0059] The slot matching parameter is obtained by the BIOS during the POST phase when reading the PCIe configuration space of the server expansion device, along with the slot type information (e.g., PCIe x16 slot, PCIe x8 slot, Riser card slot, etc.). This slot type information is transmitted to the BMC as a supplementary field along with the hardware identification data. The link bandwidth matching parameter is obtained by the BIOS during the POST phase by reading the link status register in the PCIe configuration space, obtaining the actual negotiated link width (e.g., x1, x4, x8, x16, etc.) of the server expansion device. This link width is also transmitted to the BMC as a supplementary field along with the hardware identification data. The model matching parameter is obtained by the BMC through the out-of-band management interface (the communication interface used by the BMC when providing management functions), obtaining the current server model information (e.g., rack server model, GPU server model, etc.). This model information is server-level configuration information maintained locally by the BMC. The authentication status parameter can be obtained from the component authentication status database maintained locally by the BMC.

[0060] Based on the above, the server expansion component asset information statistical method involves the BMC receiving data sub-packets sent by the BIOS. Each data sub-packet is obtained by the BIOS grouping the hardware identification data of the server expansion device and encapsulating it with a sub-packet sequence number. The BMC parses each data sub-packet to obtain the sub-identification data and the corresponding sub-packet sequence number. Based on the sub-packet sequence number, multiple groups of sub-identification data are concatenated to restore the complete hardware identification data. The hardware identification data is extracted to obtain multiple sets of target fields. Finally, each set of target fields is hierarchically matched with a preset resource mapping table to obtain the asset information corresponding to the server expansion device.

[0061] This application introduces packet sequence numbers when the BIOS sends hardware identification data. This allows the BMC to sequentially reassemble multiple sets of sub-identification data according to the sequence numbers at the receiving end, restoring the complete hardware identification data. This ensures that even if packet transmission is out of order or partially lost during cross-firmware transmission of hardware identification data from the BIOS to the BMC, the BMC can still accurately reconstruct the complete data based on the packet sequence numbers, avoiding hardware identification data corruption or incompleteness caused by unreliable transmission. Furthermore, by introducing hierarchical matching, it automatically degrades to partial matching or wildcard matching when a match fails, giving the device identification process fault tolerance and adaptability. Ultimately, this improves the accuracy of extended component asset information statistics.

[0062] Based on the above embodiments, this embodiment provides a detailed explanation of the process of applying the server expansion component asset information statistics method to the server's basic input / output system BIOS, specifically including: The BIOS acquires the hardware identification data of the server expansion device; the BIOS groups the hardware identification data to obtain multiple sets of sub-identification data; the BIOS encapsulates each set of sub-identification data with its corresponding packet sequence number to obtain a data sub-packet corresponding to each set of sub-identification data; the BIOS transmits each data sub-packet to the BMC so that the BMC can parse each data sub-packet to obtain the sub-identification data and packet sequence number corresponding to each data sub-packet, and uses the packet sequence number to concatenate multiple sets of sub-identification data to obtain the hardware identification data of the server expansion device, then extracts multiple sets of target fields from the hardware identification data of the server expansion device, and then performs hierarchical matching of each set of target fields with a preset resource mapping table to obtain the asset information corresponding to the server expansion device.

[0063] During the POST phase, the BIOS scans the bus number, device number, and function number of the server expansion devices. It reads fields such as VID, DID, SubVID, Subsystem Device Identifier (SubDID), and BDF from the PCIe configuration space of the server expansion devices and combines these fields into hardware identification data. Because the single transmission capacity of the KCS channel is limited, and the total size of the hardware identification data exceeds the single packet capacity when there are many server expansion devices, the BIOS divides the hardware identification data into multiple groups of sub-identification data with a fixed payload length. Each group of sub-identification data is assigned a packet sequence number, starting from 0 and incrementing, to identify the sequential position of each group of sub-identification data within the total sub-identification data. The BIOS encapsulates each set of sub-identifier data, along with the corresponding packet sequence number, total number of packets, boot cycle identifier BootID, and the target checksum calculated from the content of that data sub-packet, into a single data sub-packet. The encapsulation format is as follows: a fixed magic number of 4 bytes at offset 0x00, a protocol version number of 2 bytes at offset 0x04, the current packet sequence number of 2 bytes at offset 0x06, the total number of packets of 2 bytes at offset 0x08, the boot cycle identifier BootID of 4 bytes at offset 0x0A, the number of records in this packet of 2 bytes at offset 0x0E, the payload length of 4 bytes at offset 0x10, the target checksum of 4 bytes at offset 0x14, and a variable-length PCIe device record array (i.e., sub-identifier data) starting at offset 0x18. The BIOS encapsulates each set of sub-identifier data in the above format, and after obtaining each data sub-packet, sends it to the BMC packet by packet through the KCS channel.

[0064] After the BIOS transmits each data sub-packet to the BMC, the BMC performs the following operations: parses each data sub-packet to obtain the sub-identifier data and the corresponding packet sequence number; based on the packet sequence number, concatenates multiple sets of sub-identifier data to obtain the hardware identification data of the server expansion device; extracts the hardware identification data of the server expansion device to obtain multiple sets of target fields; and performs hierarchical matching of each set of target fields with a preset resource mapping table to obtain the asset information corresponding to the server expansion device.

[0065] After the BIOS transmits the data sub-packets to the BMC, it also includes: Receive retransmission requests from the BMC; retrieve the sub-identifier data corresponding to the packet sequence number in the retransmission request; repackage the sub-identifier data corresponding to the packet sequence number in the retransmission request to obtain a new data sub-packet; send the new data sub-packet to the BMC.

[0066] The BIOS receives a retransmission request from the BMC, which carries the sequence number of the data sub-packet to be retransmitted. Based on the sequence number in the retransmission request, the BIOS retrieves the corresponding sub-identifier data from its local cache. The BIOS then repackages this sub-identifier data, along with the corresponding sequence number, total number of packets, BootID (boot cycle identifier), and the target checksum calculated from the data sub-packet content, into a new data sub-packet using the same encapsulation format as before. The BIOS sends the new data sub-packet to the BMC via the KCS channel. Upon receiving the retransmitted data sub-packet, the BMC performs deduplication, checksum verification, and concatenation again.

[0067] In this embodiment, the BIOS scans server expansion devices during the POST phase, reading fields such as VID, DID, SubVID, SubDID, and BDF from the PCIe configuration space and combining them into hardware identification data. This hardware identification data is then divided into multiple groups of sub-identification data with a fixed payload length, and a packet sequence number is assigned to each group. Each group of sub-identification data, along with its packet sequence number, total number of packets, BootID (boot cycle identifier), and target checksum, is encapsulated into a data sub-packet and sent to the BMC packet by packet through the KCS channel. After transmission, the BIOS receives a retransmission request from the BMC, retrieves the corresponding sub-identification data based on the packet sequence number carried in the retransmission request, re-encapsulates it, and sends it back to the BMC. This application introduces packet sequence numbers when the BIOS sends hardware identification data, enabling the BMC to sequentially assemble multiple groups of sub-identification data according to the sequence number at the receiving end to reconstruct complete hardware identification data. Furthermore, the BIOS is only responsible for the collection, grouping, encapsulation, transmission, and on-demand retransmission of hardware identification data; it does not participate in the mapping and matching process from hardware identification data to asset information, nor does it store component mapping relationships. The mapping relationship is entirely carried by the resource mapping table on the BMC side. This resource mapping table is independent of the BIOS firmware, realizing complete decoupling between the BIOS side and the mapping data. This improves the scalability and adaptability of the entire asset information statistics system. Furthermore, the packet transmission and retransmission response mechanism on the BIOS side ensures the accuracy of the input data (hardware identification data). The data source on which the final hierarchical matching is based is reliable, ultimately improving the accuracy of asset information statistics for extended components.

[0068] The above text combined Figures 1 to 2 The method for statistical analysis of server expansion component asset information provided in this application embodiment has been described in detail. The apparatus and equipment provided in this application embodiment will be described below with reference to the accompanying drawings.

[0069] This application also provides a server expansion component asset information statistics device, such as... Figure 3 As shown in the figure, this is a structural diagram of a server extension component asset information statistics device provided in an embodiment of this application. The device includes: The receiving module 301 is used to receive various data sub-packets sent by the Basic Input / Output System BIOS; wherein, each data sub-packet is obtained by the BIOS grouping the hardware identification data of the server expansion device into multiple groups of sub-identification data, and then encapsulating each group of sub-identification data with the corresponding sub-packet sequence number of each group of sub-identification data; The parsing and processing module 302 is used to parse each data sub-packet to obtain the sub-identifier data and the corresponding sub-packet sequence number in each data sub-packet; based on the sub-packet sequence number, multiple sets of sub-identifier data are concatenated to obtain the hardware identification data of the server expansion device; the hardware identification data of the server expansion device is extracted to obtain multiple sets of target fields. The asset matching module 303 is used to perform hierarchical matching of each set of target fields with a preset resource mapping table to obtain the asset information corresponding to the server extension device.

[0070] In some possible implementations, the server extension component asset information statistics device also includes: The verification module is used to extract the packet sequence number and target verification value from each data sub-packet; based on the packet sequence number, it performs deduplication processing on each data sub-packet to obtain deduplicated data sub-packets; based on the target verification value, it verifies each deduplicated data sub-packet to identify data sub-packets that fail verification; it discards the data sub-packets that fail verification and sends a retransmission request for the data sub-packets that fail verification to the BIOS.

[0071] In some possible implementations, the server extension component asset information statistics device also includes: The missing packet check module is used to extract the packet sequence number from each data sub-packet; based on the packet sequence number, the data sub-packets are sorted to determine the missing packet sequence number; for the missing packet sequence number, a retransmission request for the data sub-packet with the missing packet sequence number is sent to the BIOS.

[0072] In some possible implementations, the asset matching module 303 is specifically used for: For each set of target fields, the target fields are used as the first search key to perform a match in the first matching table, resulting in a first matching result. If the first matching result is not empty, the asset information corresponding to the server extension device is determined based on the first matching result. If the first matching result is empty, the first identifier, second identifier, and first code in the target fields are used as the second search key to perform a match in the second matching table, resulting in a second matching result. If the second matching result is not empty, the asset information corresponding to the server extension device is determined based on the second matching result. If the second matching result is empty, the first identifier and second identifier in the target fields are used as the third search key to perform a match in the third matching table, resulting in a third matching result. If the third matching result is not empty, the asset information corresponding to the server extension device is determined based on the third matching result. If the third matching result is empty, the device is determined to be an unknown device.

[0073] In some possible implementations, the server extension component asset information statistics device also includes: A mapping table construction module is used to receive the component information configuration table; parse each record in the component information configuration table to determine the first identifier, second identifier, first code, second code, and corresponding asset information field in each record; construct a first matching table based on the first identifier, second identifier, first code, second code, and corresponding asset information field; construct a second matching table based on the first identifier, second identifier, first code, and corresponding asset information field; construct a third matching table based on the first identifier, second identifier, and corresponding asset information field; and construct a preset resource mapping table based on the first, second, and third matching tables.

[0074] This application also provides another server expansion component asset information statistics device, such as... Figure 4 As shown in the figure, this is a structural diagram of another server extension component asset information statistics device provided in an embodiment of this application. The device includes: The acquisition module is used by the BIOS to acquire hardware identification data of server expansion devices; The encapsulation module is used by the BIOS to group hardware identification data into multiple groups of sub-identification data; the BIOS encapsulates each group of sub-identification data with its corresponding packet sequence number to obtain the data sub-packet corresponding to each group of sub-identification data. The transmission module is used by the BIOS to transmit data sub-packets to the Baseboard Management Controller (BMC). The BMC then parses each data sub-packet to obtain the corresponding sub-identifier data and sub-packet sequence number. Using the sub-packet sequence number, multiple sets of sub-identifier data are concatenated to obtain the hardware identification data of the server expansion device. The hardware identification data of the server expansion device is then extracted to obtain multiple sets of target fields. Each set of target fields is then matched hierarchically with a preset resource mapping table to obtain the asset information corresponding to the server expansion device.

[0075] In some possible implementations, the server extension component asset information statistics device also includes: The repackaging module is used to receive retransmission requests from the BMC; based on the packet sequence number in the retransmission request, it retrieves the sub-identifier data corresponding to the packet sequence number in the retransmission request; it repackages the sub-identifier data corresponding to the packet sequence number in the retransmission request to obtain a new data sub-packet; and it sends the new data sub-packet to the BMC.

[0076] The server expansion component asset information statistics device according to the embodiments of this application can correspondingly execute the method described in the embodiments of this application, and the other operations and / or functions of each module / unit of the server expansion component asset information statistics device are respectively for implementing Figure 2 For the sake of brevity, the corresponding processes of each method in the illustrated embodiments will not be described in detail here.

[0077] This application also provides a computing device. For example... Figure 4 As shown in the figure, this is a schematic diagram of a computing device provided in an embodiment of this application. The computing device 400 includes a bus 401, a processor 402, a communication interface 403, and a memory 404. The processor 402, the memory 404, and the communication interface 403 communicate with each other via the bus 401.

[0078] Bus 401 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0079] Processor 402 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0080] Communication interface 403 is used for communication with external devices.

[0081] Memory 404 may include volatile memory, such as random access memory (RAM). Memory 404 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0082] The memory 404 stores executable code, and the processor 402 executes the executable code to perform the aforementioned server extension component asset information statistics method.

[0083] Specifically, in achieving Figure 3 In the case of the illustrated embodiment, and Figure 3 When the modules or units of the server extension component asset information statistics device described in the embodiment are implemented through software, the execution... Figure 3 The software or program code required for the functions of each module / unit can be partially or entirely stored in memory 404. Processor 402 executes the program code corresponding to each unit stored in memory 404, and executes the aforementioned server extension component asset information statistics method.

[0084] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the aforementioned server expansion component asset information statistics method.

[0085] This application also provides a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application are generated.

[0086] The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another website, computer, or data center via wired (e.g., coaxial cable, fiber optic) or wireless (e.g., infrared, microwave, etc.) means.

[0087] When the computer program product is executed by a computer, the computer executes any of the aforementioned methods of the server expansion component asset information statistics method. The computer program product can be a software installation package; when any of the aforementioned methods of the server expansion component asset information statistics method is required, the computer program product can be downloaded and executed on the computer.

[0088] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0089] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the scope of protection of this application.

Claims

1. A method for statistical analysis of server expansion component asset information, characterized in that, The method, applied to a baseboard management controller (BMC) for servers, includes: Receive data sub-packets sent by the Basic Input / Output System (BIOS); wherein, each data sub-packet is obtained by the BIOS grouping the hardware identification data of the server expansion device into multiple groups of sub-identification data, and then encapsulating each group of sub-identification data with the corresponding packet sequence number of each group of sub-identification data; Each data sub-packet is parsed to obtain the sub-identifier data and the corresponding sub-packet sequence number in each data sub-packet; Based on the packet sequence number, multiple sets of sub-identifier data are concatenated to obtain the hardware identification data of the server extension device. Extract the hardware identification data of the server expansion device to obtain multiple sets of target fields; Each set of target fields is matched hierarchically with a preset resource mapping table to obtain the asset information corresponding to the server extension device.

2. The method according to claim 1, characterized in that, After receiving the data sub-packets sent by the Basic Input / Output System BIOS, the method further includes: Extract the packet sequence number and target verification value from each data sub-packet; Based on the packet sequence number, each data sub-packet is deduplicated to obtain the deduplicated data sub-packet; Based on the target verification value, each deduplicated data sub-packet is verified to identify the data sub-packets that fail the verification. The data sub-packets that fail verification are discarded, and a retransmission request for the data sub-packets that fail verification is sent to the BIOS.

3. The method according to claim 1, characterized in that, After receiving the data sub-packets sent by the Basic Input / Output System BIOS, the method further includes: Extract the sub-packet sequence number from each data sub-packet; Based on the sub-packet sequence number, sort the data sub-packets and determine the missing sub-packet sequence number; For any missing packet sequence number, a retransmission request for the data sub-packet with the missing sequence number is sent to the BIOS.

4. The method according to claim 1, characterized in that, The resource mapping table includes a first matching table, a second matching table, and a third matching table. The matching accuracy of the first matching table is higher than that of the second matching table, and the matching accuracy of the second matching table is higher than that of the third matching table. The step of performing hierarchical matching of each set of target fields with the preset resource mapping table to obtain the asset information corresponding to the server extension device includes: For each set of target fields, the target fields are used as the first search key to perform a match in the first matching table to obtain the first matching result; if the first matching result is not empty, the asset information corresponding to the server extension device is determined based on the first matching result. If the first matching result is empty, the first identifier, the second identifier, and the first code in the target field are used as the second search key to perform a match in the second matching table to obtain the second matching result; if the second matching result is not empty, the asset information corresponding to the server extension device is determined based on the second matching result. If the second matching result is empty, the first and second identifiers in the target fields of this group are used as the third search key to perform matching in the third matching table to obtain the third matching result; if the third matching result is not empty, the asset information corresponding to the server extension device is determined based on the third matching result. If the third matching result is empty, then it is determined to be an unknown device.

5. The method according to claim 1, characterized in that, The method further includes: Receiver component information configuration table; Each record in the component information configuration table is parsed to determine the first identifier, second identifier, first code, second code, and corresponding asset information fields in each record; Based on the first identifier, the second identifier, the first code, the second code, and the corresponding asset information fields, a first matching table is constructed; A second matching table is constructed based on the first identifier, the second identifier, the first code, and the corresponding asset information fields; Based on the first identifier, the second identifier, and the corresponding asset information fields, a third matching table is constructed; Based on the first matching table, the second matching table, and the third matching table, a preset resource mapping table is constructed.

6. A method for statistical analysis of server expansion component asset information, characterized in that, The method, applied to the Basic Input / Output System (BIOS) of a server, includes: BIOS obtains hardware identification data of server expansion devices; The BIOS groups the hardware identification data to obtain multiple groups of sub-identification data; The BIOS encapsulates each group of sub-identifier data with the corresponding packet sequence number of each group of sub-identifier data to obtain the data sub-packet corresponding to each group of sub-identifier data. The BIOS transmits data sub-packets to the Baseboard Management Controller (BMC), which then parses each data sub-packet to obtain the corresponding sub-identifier data and sub-packet sequence number. The sub-packet sequence number is used to concatenate multiple sets of sub-identifier data to obtain the hardware identification data of the server expansion device. The hardware identification data of the server expansion device is then extracted to obtain multiple sets of target fields. Each set of target fields is then matched hierarchically with a preset resource mapping table to obtain the asset information corresponding to the server expansion device.

7. The method according to claim 6, characterized in that, After the BIOS transmits each data sub-packet to the Baseboard Management Controller (BMC), it also includes: Receive retransmission requests from the BMC; Based on the packet sequence number in the retransmission request, retrieve the sub-identifier data corresponding to the packet sequence number in the retransmission request; The sub-identifier data corresponding to the sequence number of the retransmission request is re-encapsulated to obtain a new data sub-packet; Send the new data sub-packet to the BMC.

8. A server expansion component asset information statistics device, characterized in that, The device includes: The receiving module is used to receive data sub-packets sent by the Basic Input / Output System (BIOS); wherein, each data sub-packet is obtained by the BIOS grouping the hardware identification data of the server expansion device into multiple groups of sub-identification data, and then encapsulating each group of sub-identification data with the corresponding packet sequence number of each group of sub-identification data. The parsing and processing module is used to parse each data sub-packet to obtain the sub-identifier data and the corresponding sub-packet sequence number in each data sub-packet; based on the sub-packet sequence number, multiple sets of sub-identifier data are concatenated to obtain the hardware identification data of the server expansion device; the hardware identification data of the server expansion device is extracted to obtain multiple sets of target fields; The asset matching module is used to perform hierarchical matching of each set of target fields with a preset resource mapping table to obtain the asset information corresponding to the server extension device.

9. A computing device, characterized in that, Including memory and processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the method as described in any one of claims 1 to 7.

Images