Methods and apparatus for allocating communication resources, storage media and electronic equipment

Abstract

This application discloses a method and apparatus for allocating communication resources, a storage medium, and an electronic device, relating to the field of storage system technology. The method includes: when the server is powered on, acquiring the status of each component of the server; determining the processing status corresponding to at least one first component, where the first component is a pluggable device, and the processing status indicates whether the first component is allocating communication resources; if at least one first component includes a second component that has not been allocated communication resources, determining the target communication resource corresponding to the second component in a resource configuration table using the device information of the second component; configuring the target communication resource corresponding to the second component, and marking the second component as a third component, where the third component is a first component that has been allocated communication resources. This solves the problem of low overall server performance in related technologies' communication resource allocation methods, achieving the technical effect of improving server performance.

Description

Technical Field

[0001] This application relates to the field of storage systems, and more particularly to a method and apparatus for allocating communication resources, a storage medium, and an electronic device. Background Technology

[0002] In the fields of data centers and high-performance computing, heterogeneous computing architectures have become mainstream, with the integration of high-performance devices such as GPUs (Graphics Processing Units), DPUs (Data Processing Units), and CXLs (Compute Express Links) becoming increasingly common. However, these devices have varying requirements for Fabric resources, namely the infrastructure that supports high-speed interconnection between CPU cores and other IP components, and often far exceed the requirements of standard server configurations.

[0003] In related technologies, Fabric resource allocation often relies on hard-coding, meaning that resource allocation information is directly written into the BIOS (Basic Input / Output System) or UEFI (Unified Extensible Firmware Interface) firmware during server production based on the expected hardware configuration. While this method provides a certain degree of stability and optimization, when server hardware configurations change, such as adding or replacing high-performance devices, the hard-coded resource allocation strategy often cannot adapt automatically, requiring manual customization of the BIOS version. This not only increases maintenance costs but also reduces system adaptability and efficiency. In other words, the communication resource allocation methods in related technologies suffer from relatively low overall server performance. Summary of the Invention

[0004] This application provides a method and apparatus for allocating communication resources, a storage medium and an electronic device, to at least solve the problem of low overall server performance in communication resource allocation methods in related technologies.

[0005] This application provides a method for allocating communication resources, including: obtaining the status of each component of the server when the server is powered on;

[0006] In the case where the server includes at least one first component, the processing state corresponding to each of the at least one first component is determined, wherein the first component is a pluggable device, and the processing state is used to indicate whether the first component performs communication resource allocation.

[0007] In the case where at least one first component includes a second component for which no communication resources have been allocated, the target communication resources corresponding to the second component are determined in the resource configuration table using the device information of the second component.

[0008] Configure the target communication resources corresponding to the second component, and mark the second component as the third component, wherein the third component is the first component for which communication resources have been allocated.

[0009] This application also provides a communication resource allocation device, including: a status acquisition module, used to acquire the status of various components of the server when the server is powered on;

[0010] The component status determination module is used to determine the processing status of each of the at least one first component when the server includes at least one first component, wherein the first component is a pluggable device and the processing status is used to indicate whether the first component performs communication resource allocation.

[0011] A resource determination module is used to determine the target communication resource corresponding to the second component in a resource configuration table by using the device information of the second component when at least one first component includes a second component for which no communication resource allocation has been performed.

[0012] The resource allocation module is used to configure the target communication resources corresponding to the second component and mark the second component as the third component, wherein the third component is the first component that has been allocated communication resources.

[0013] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described communication resource allocation methods when executing the computer program.

[0014] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described communication resource allocation methods.

[0015] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described methods for allocating communication resources.

[0016] This application describes a method for allocating resources to a server when it is powered on. If the server includes at least one first component, the system determines the processing status of each component, where the first component is a pluggable device and the processing status indicates whether the first component is allocating communication resources. If at least one first component includes a second component that has not been allocated communication resources, the system uses the device information of the second component to determine the target communication resource corresponding to the second component in a resource configuration table. The system then configures the target communication resource corresponding to the second component and marks the second component as a third component, where the third component is a first component that has been allocated communication resources. For a second component that has not yet been allocated communication resources, the system uses the device information stored on it (such as device ID, vendor ID, etc.) to search for a matching entry in the resource configuration table to determine the target communication resource. This method utilizes software intelligence rather than hardware coding to allocate resources to devices, achieving high flexibility and scalability. Precise lookup and configuration avoid over-allocation and waste of resources, maximizing the utilization efficiency of Fabric resources. Attached Figure Description

[0017] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the hardware environment for an optional communication resource allocation method according to an embodiment of this application;

[0019] Figure 2 This is a flowchart of an optional method for allocating communication resources according to an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of an optional resource data according to an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of an optional method for allocating communication resources according to an embodiment of this application;

[0022] Figure 5 This is a flowchart of another optional method for allocating communication resources according to an embodiment of this application;

[0023] Figure 6 This is a structural block diagram of an optional communication resource allocation device according to an embodiment of this application. Detailed Implementation

[0024] 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 embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0025] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0026] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] According to one aspect of the embodiments of this application, a method for allocating communication resources is provided. As an optional implementation, the above-described method for allocating communication resources can be applied, but is not limited to, to applications such as... Figure 1 The hardware environment shown includes a communication resource allocation system. This communication resource allocation system may include, but is not limited to, a host unit 102, a controller 104, and several server components 106. The system may be an internal structure of a server.

[0028] The host unit 102 is the main computing unit of the server, responsible for executing the operating system and applications. The controller 104 can be a Baseboard Management Controller (BMC). The BMC is a key component for server hardware management; it runs independently of the host operating system and can provide server status monitoring and management capabilities even when the host system is not powered on or has crashed. After the server is powered on, the BIOS program runs on the CPU core of the host unit to initialize the core and cache. This step ensures that the core and cache can communicate with Fabric and access Fabric-related hardware registers. The host unit initializes the IPMI hardware link and software interface, establishing communication capabilities with the BMC. This means that the CPU core can directly communicate with the BMC via the IPMI protocol to obtain or update Fabric resource data. The host unit requests Fabric resource data from the BMC unit using OEM-customized IPMI commands. If data acquisition or verification fails, the host unit will allocate resources according to traditional fixed allocation logic; if data acquisition is successful and verification passes, the host unit will configure the relevant Fabric registers according to the Fabric resource data protocol to complete dynamic resource allocation.

[0029] Assume the server contains two CPUs, a series of UMC memory controllers, and multiple pluggable I / O devices (such as GPUs, DPUs, and CXL devices). During the POST phase of server startup, the host unit requests Fabric resource data from the BMC unit via IPMI commands. The BMC unit responds to the request, reads data from the EEPROM, and provides it to the host unit. Upon receiving the data, the host unit verifies its validity and applicability. If verification succeeds, the host unit dynamically allocates Fabric resources based on the data, such as allocating more MMIO resources to the GPU, more bus resources to the DPU, and flexible memory space layout to the CXL devices to improve overall performance. If verification fails, the host unit will use the default hard-coded allocation logic to ensure basic server operation, but resource allocation may be less efficient than the dynamic method. After resource allocation is complete, the new resource configuration state is stored back in the BMC's EEPROM for quick application upon the next server startup.

[0030] Embodiments of this application provide a method for allocating communication resources. Figure 2 This is a flowchart of an optional communication resource allocation method according to an embodiment of this application; this method can be executed by a host unit, such as... Figure 2 As shown, the method for allocating communication resources includes:

[0031] Step S202: With the server powered on, obtain the status of each component of the server;

[0032] It's important to note that "powering on" refers to the process of a server transitioning from a shutdown state to a running state. This process includes hardware detection, initialization, and software loading, ultimately enabling the operating system to run. The status of individual components refers to the current operating status and configuration information of all hardware components within the server (such as the CPU, GPU, DPU, UMC, I / O devices, etc.). This status information can include whether the components are present, operating temperature, voltage level, performance parameters, and communication resource allocation.

[0033] In an optional implementation, the real-time status of all hardware components within the server is read and inspected. This includes, but is not limited to, the status of the CPU cores, the operating status of the memory controller (UMC), the connection status of I / O devices, and the configuration information of specific heterogeneous computing components (such as GPUs and DPUs).

[0034] In the server startup process, the POST (Power-On Self-Test) phase is a crucial first step. During this phase, the host BIOS program actively queries the server's hardware status to ensure the correct configuration and normal operation of all critical hardware components. Through interaction with the BMC (Baseboard Management Controller), the system can obtain detailed status information on core components including the CPU, UMC, and xGMI, as well as pluggable devices such as the GPU, DPU, and CXL. This information includes not only whether the hardware is present and functioning correctly, but more importantly, it contains the current requirements and allocation of Fabric resources (such as PCI configuration space, MMIO resources, port I / O resources, configuration space resources, memory space layout, etc.).

[0035] In an optional implementation, the BMC reads and maintains hardware status information, which the host unit queries via IPMI commands. Furthermore, the BMC also maintains Fabric resource data in the EEPROM to ensure that it receives the latest hardware configuration and resource allocation information regardless of the server's state.

[0036] Step S204: In the case that the server includes at least one first component, determine the processing state corresponding to each of the at least one first component, wherein the first component is a pluggable device, and the processing state is used to indicate whether the first component performs communication resource allocation.

[0037] It should be noted that communication resources can be Fabric resource data, including the following resources:

[0038] Bus resources, including PCIe bus and other resources, determine how devices communicate with Fabric and the allocation of buses, such as the number and speed level of PCIe lanes. This has a significant impact on the performance of I / O devices such as GPUs, DPUs, and network adapters.

[0039] Memory-Mapped I / O (MMIO) resources allow the processor to control peripheral devices via memory read and write commands. For example, MMIO can be used to access the GPU's video memory or configure its functions. The size and location of MMIO resources directly affect the device's performance and functionality.

[0040] Port I / O resources: Traditional I / O resources used for direct access to device registers. Although MMIO has become more common in modern servers, some devices or functions may still rely on port I / O.

[0041] Memory space layout: This includes how the address space of the memory controller is allocated, and how memory regions are mapped to various nodes in the Fabric. Memory access patterns and allocation strategies have a significant impact on the overall performance and stability of the server.

[0042] Configuration Space: Space used to store device configuration information, such as PCI configuration space, which contains the device's capabilities, status, and configuration options.

[0043] The first component refers to pluggable devices within the server, such as GPUs, DPUs, and CXL devices. These components differ from those permanently mounted on the motherboard; they can be inserted or removed by the user as needed. The processing status refers to whether the pluggable device has completed the necessary allocation of communication resources. Communication resources include, but are not limited to, bus resources, MMIO resources, port I / O resources, and memory space layout. Proper allocation of these resources is a prerequisite for ensuring normal communication between the device and other parts of the server.

[0044] In an optional implementation, as long as one or more pluggable devices (first component) exist within the server, the server will actively detect the processing status of these devices to determine whether the devices have completed the allocation of communication resources. This determination is crucial for the normal operation of the devices—if a device has not yet been allocated the corresponding resources, it will not be able to participate in the server's system communication and will therefore be unable to perform its intended functions.

[0045] In server management, especially for modern servers with high flexibility and scalability, the ability to dynamically identify and manage the communication resources of pluggable devices is becoming increasingly important. The existence of pluggable devices allows servers to flexibly add or replace specific types of hardware resources, such as GPU accelerator cards, DPU network processors, or CXL memory expansion modules, according to different workloads and application requirements. However, this flexibility also brings a series of challenges, the primary one being how to ensure that newly inserted devices can immediately obtain the necessary communication resources without conflicting with existing hardware resources.

[0046] After the server powers on and begins the POST process, the system performs a full hardware scan, identifying all pluggable devices and checking whether they have been correctly allocated resources. This check is done by reading device identifiers, comparing them against a preset resource configuration table, and even by attempting simple communication with the device. For devices that have not yet been allocated resources (i.e., those whose processing status indicates no communication resource allocation), the server triggers a resource allocation process, automatically allocating appropriate resources based on device type, server topology, and other preset rules.

[0047] Step S206: In the case where at least one first component includes a second component for which no communication resources have been allocated, the target communication resources corresponding to the second component are determined in the resource configuration table using the device information of the second component.

[0048] It should be noted that the second component is a subset of the first component, specifically referring to pluggable devices that have not yet been allocated communication resources in the current system state. These devices may be dynamically inserted after system startup, or their resources may not be allocated in a timely manner due to changes in system configuration. Device information may include the device ID, vendor ID, type, and other identifying characteristics. This information is stored in the device itself or in the system database to identify the device's specific needs and attributes. The resource configuration table can be a data structure or database used to store the mapping relationship between different types of devices and their required communication resources. By retrieving this table, the system can quickly determine the device's requirements and allocate resources. Target communication resources refer to specific communication resources, such as bus resources and MMIO resources, determined by the system based on the device information of the second component through the resource configuration table, used to meet the device's functional and performance requirements.

[0049] In modern server architectures, the addition of high-performance computing resources such as GPUs, DPUs, and CXL devices places higher demands on system resource management. Traditional hard-coded resource allocation methods are inadequate in meeting these requirements because they lack adaptability to new devices and configuration changes. Therefore, the method proposed in this application establishes an updatable resource configuration table, enabling the system to identify devices in real time and dynamically find suitable resources based on device information. This mechanism not only improves the efficiency of resource allocation but also reduces the need for frequent system firmware or software updates, lowering maintenance costs. Furthermore, it enhances the server's compatibility and response speed to different types of device access, enabling it to better serve ever-evolving computing scenarios.

[0050] In an optional implementation, the BIOS program running on the CPU core first reads device information provided by the BMC (Baseboard Management Controller), which may include device type, ID, manufacturer, etc. The BIOS program then uses this information as a lookup key to access a resource configuration table stored in memory or non-volatile storage (such as EEPROM). This table contains resource requirement mappings for various device types. Through matching, the system can quickly locate the type and quantity of resources required by the second component (i.e., the device without allocated resources), thus enabling precise allocation. This approach ensures rational resource allocation, avoids resource waste and device conflicts, and enhances the overall operating efficiency and stability of the server.

[0051] Step S208: Configure target communication resources corresponding to the second component for the second component, and mark the second component as the third component, wherein the third component is the first component for which communication resources have been allocated.

[0052] It should be noted that once the second component is allocated target communication resources, it is marked as the third component. This means that the pluggable device is already the first component after the communication resources have been allocated, and can perform normal hardware communication and function execution.

[0053] In an optional implementation, the system allocates the most suitable communication resources to the device based on its specific needs and the current resource allocation. This step ensures effective interaction between the devices within the server architecture. Subsequently, the device's state is updated, transitioning from a state without resource allocation (second component) to a state with allocated resources (third component). This marking mechanism facilitates subsequent resource management and maintenance, ensuring transparency and controllability in server resource usage.

[0054] Example 1:

[0055] Assuming the server performs a POST self-test after power-on, the system obtains the server's hardware status through the BMC unit (step S202) and identifies a GPU accelerator card that has not been allocated communication resources (the second component identified in step S204). Next, the system reads the GPU accelerator card's device ID and vendor ID, and uses this information to query the preset resource configuration table (step S206), ultimately determining that the GPU accelerator card requires a large MMIO resource area and additional bus resources. Subsequently, the server's BIOS program dynamically adjusts the current Fabric resource layout based on this requirement, reserving sufficient MMIO space and bus resources for the GPU accelerator card (implementation of step S208), and updates the internal resource allocation status, marking the GPU accelerator card as a component with configured resources (the third component), ensuring that the GPU can be successfully initialized and enabled during the subsequent boot process.

[0056] This application describes a method for allocating resources to a server when it is powered on. If the server includes at least one first component, the system determines the processing status of each component, where the first component is a pluggable device and the processing status indicates whether the first component is allocating communication resources. If at least one first component includes a second component that has not been allocated communication resources, the system uses the device information of the second component to determine the target communication resource corresponding to the second component in a resource configuration table. The system then configures the target communication resource corresponding to the second component and marks the second component as a third component, where the third component is a first component that has been allocated communication resources. For a second component that has not yet been allocated communication resources, the system uses the device information stored on it (such as device ID, vendor ID, etc.) to search for a matching entry in the resource configuration table to determine the target communication resource. This method utilizes software intelligence rather than hardware coding to allocate resources to devices, achieving high flexibility and scalability. Precise lookup and configuration avoid over-allocation and waste of resources, maximizing the utilization efficiency of Fabric resources.

[0057] In an optional implementation, before determining the target communication resource corresponding to the second component in the resource configuration table using the device information of the second component, the method includes: reading the device information of the second component, wherein the device information is used to indicate the device type and production identifier of the second component; querying the interaction interface of the second component based on the device information of the second component; if the interaction interface defines a reference communication resource, allocating a reference communication resource to the second component, and marking the second component as a third component.

[0058] It should be noted that device information includes the device ID and vendor ID, used to identify the device type and manufacturer, and is the foundation for the system to identify and process the device. The interaction interface refers to the specific hardware or software interface used for communication between the device and the server system, such as the DVSEC (Designated Vendor-Specific Extended Capability) register defined in the PCIe specification, used for reporting device-defined capabilities. Reference communication resources can be the communication resources that the device may need, defined in the device's interaction interface, and can serve as a reference for the system to allocate resources.

[0059] In an optional implementation, before the system attempts to find target communication resources for the second component (i.e., the pluggable device) that has not been allocated resources, it needs to read the device information. Device information is crucial for the system to identify the device type and manufacturer, and is essential for correct resource allocation. Based on the read device information, the system further queries the device's interaction interface. Different device types may have different interface definitions; querying the interaction interface is to gain a deeper understanding of the device's characteristics, especially the communication resource information it may need. If a defined reference communication resource is found in the queried interaction interface, the system will allocate the corresponding communication resources to the second component (the device without allocated resources) based on this information. After resource allocation is completed, the device is upgraded from the second component (unallocated resource state) to the third component (allocated resource state), indicating that resource allocation is complete and the device is ready to participate in system communication.

[0060] In an optional implementation, in a server-managed dynamic resource allocation scenario, for a newly inserted pluggable device (the second component), the system first needs to perform a series of identification and information acquisition tasks. Starting with reading device information, the system can determine the device type and manufacturer; this is the first step in the resource allocation process. Next, the system queries the device's interaction interfaces, especially those defined in the device's standard specifications, such as the DVSEC register in the PCIe specification, to obtain information related to the device's communication resource requirements. If these interfaces define communication resource requirements, the system will directly allocate resources to the device based on this information. In this case, the device is considered processed (the third component) and can immediately participate in system communication.

[0061] During the server POST phase, the BIOS program reads device information for all pluggable devices, including device ID and vendor ID, through communication with the BMC unit. For devices without allocated communication resources (secondary components), the BIOS queries the device's interaction interface based on its device information, specifically querying the interfaces defined in the standard specification based on the device type. If the interaction interface defines reference communication resources, the BIOS immediately allocates these resources to the device and marks the device as a tertiary component after allocation, indicating that its resource allocation status is processed. For devices without reference communication resources defined in the interaction interface, the system enters a feedback mechanism, determines resource requirements based on the device's default needs or through testing, and then allocates resources.

[0062] Through the above-described embodiments of this application, the server can automatically identify and adapt to newly inserted pluggable devices, ensuring that they can be quickly and safely integrated into the system, thereby improving the efficiency of resource allocation and the operational stability of the server.

[0063] In an optional implementation, the target communication resource corresponding to the second component is determined in the resource configuration table using the device information of the second component. This includes: if no reference communication resource is defined in the interaction interface, searching for a communication resource matching the device information in the resource configuration table using the device information of the second component; if no communication resource matching the device information is found in the resource configuration table, allocating a candidate communication resource to the second component; and if a communication resource matching the device information is found in the resource configuration table, determining the communication resource matching the device information as the target communication resource.

[0064] It should be noted that the resource allocation table can be a predefined data structure or database that stores the communication resource requirements and allocation suggestions for various device types and manufacturers. It forms the basis for the system's intelligent decision-making regarding resource allocation.

[0065] In an optional implementation, the system searches the resource configuration table for records that match the information of the second component device—that is, devices the system "recognizes." If a match is found, the system allocates resources to the device according to preset resource requirements. This step is direct and efficient, ensuring that the resource allocation for known devices meets their expected functional requirements. Conversely, if no matching device information is found in the resource configuration table, it may mean that the device is a new type that the system did not anticipate or comes from an uncommon manufacturer. In this case, the system adopts a more cautious strategy, conducting preliminary device function tests by allocating candidate communication resources and adjusting resource allocation based on the test results to ensure that the device can start normally and perform basic communication under limited resource conditions.

[0066] During the POST phase of the server, the resource allocation process needs to handle diverse pluggable devices. Whether it's a common GPU accelerator card, a DPU network processor, or an emerging CXL memory expansion module, all need to be accurately identified and properly configured by the system. After receiving device information from the second component, the system searches for the best match in a pre-built resource configuration table. This process is similar to querying a database; the system compares the device ID and vendor ID stored in the table to locate the standard resource requirements of a specific device. If a match is found, the system directly allocates the associated target communication resources. This process is both fast and accurate, ensuring that the device can initialize according to its designed performance specifications. However, for unknown devices not in the resource configuration table, the system needs to take a more conservative and flexible approach, allocating a set of candidate communication resources first. These resources are usually preset based on general standards or device categories, covering the basic needs of most devices, but may lack specific functionalities. The system monitors the device's operation during initial startup and adjusts resource allocation based on the device's actual performance. This avoids resource waste while ensuring normal device startup and initial functional testing. Once it is determined that candidate communication resources can meet the device's startup requirements, the system will officially designate these resources as target communication resources, completing the transition from the second component to the third component, i.e., the device has successfully configured its resources. This feedback-based resource allocation mechanism is not only applicable to the automated configuration of known devices, but also provides a solution for the adaptive configuration of unknown devices, improving the intelligence and compatibility of server resource management.

[0067] Example 2:

[0068] In practice, the joint operation of the BIOS and BMC is crucial to implementing the above resource allocation process. The BIOS program is responsible for reading device information and allocating resources, while the BMC maintains the resource configuration table and Fabric resource data in the EEPROM. The following are specific feasible implementation methods for this step:

[0069] During the POST phase, the BIOS reads device information from the second component, including key identifiers such as device ID and vendor ID, and then compares it with records in the resource configuration table to find a match. For known devices (i.e., those with a match in the table): the BIOS directly allocates target communication resources to the device according to the resource requirements defined in the table. After resource allocation, the BIOS marks the device as a third component, indicating that resources have been allocated. For unknown devices (those without a match in the table): the BIOS allocates a basic set of candidate communication resources, allowing the device to perform basic boot and functional tests. Subsequently, the BIOS monitors the device's operating status. If the device operates normally, it formally confirms these candidate resources as target communication resources; if the device's functionality is limited or abnormal, it may be necessary to reassess resource requirements or even adjust the resource allocation strategy. Regardless of whether the target communication resource is directly allocated or promoted from a candidate state, the BIOS sends this configuration information to the BMC, which updates the Fabric resource data in the EEPROM to form a new resource layout scheme. This update is not only temporary but is also saved for quick identification and configuration during the next server boot, avoiding repeated resource allocation processes.

[0070] In the embodiments described above, assuming the server identifies a new CXL memory expansion module during the POST phase, but its device ID and vendor ID do not appear in the preset resource configuration table, the system will allocate a set of candidate communication resources based on the CXL standard to the CXL module, including a portion of the MMIO area and bus resources. The BIOS monitors the module's boot process and finds that the module can read and write memory data normally, indicating that the initial resource allocation was successful. Therefore, the BIOS formally identifies these candidate resources as target communication resources and records this resource allocation scheme in the EEPROM through the BMC unit. When the server boots in the future, the system will directly read the configuration in the EEPROM, skipping the resource allocation exploration phase and directly providing the CXL module with verified and valid communication resources, significantly accelerating the boot speed while ensuring stable module operation. This resource allocation based on device information and feedback demonstrates the system's intelligence and flexibility in handling the diverse and high-performance hardware requirements of modern server environments.

[0071] In an optional implementation, if no communication resource matching the device information is found in the resource configuration table, a candidate communication resource is allocated to the second component, including: allocating the i-th candidate communication resource to the second component and testing the second component; if the second component is operating normally, determining the i-th candidate communication resource as a candidate communication resource; if the second component is operating abnormally, allocating the (i+1)-th candidate communication resource to the second component, and if the second component is operating normally, determining the (i+1)-th candidate communication resource as a candidate communication resource.

[0072] It should be noted that the i-th candidate communication resource refers to the initial communication resource allocated to the unknown device (second component) in the first iteration or a certain iteration. Here, "i" is a variable representing the number of allocations or the stage of the attempt.

[0073] In an optional implementation, when encountering an unknown device in server resource management, the system adopts a step-by-step, trial-and-error resource allocation strategy. The server first allocates a preliminary set of communication resources to the device (i.e., the i-th candidate communication resource), then starts the device and performs functional tests to verify whether these resources are sufficient to meet the device's basic operational requirements. If the device can operate normally after receiving the i-th candidate communication resource, the system formally confirms these resources as suitable candidate communication resources for the device, laying the foundation for further fine-tuning of resource configuration. When faced with an unknown device and the initially allocated resources fail to get the device running, the system does not give up but adopts a gradual approach, allocating more resources (the (i+1)-th candidate communication resource) and testing again. If the device can operate normally under this new resource configuration, these resources become new candidate communication resources, and the system continues to observe and test until the most suitable resource configuration is found.

[0074] In an optional implementation, during the server POST phase, if the system fails to find a match in the resource configuration table using its device information (device ID, vendor ID, etc.), indicating an unrecognized or unprocessed pluggable device (second component), a more flexible and exploratory resource allocation strategy is required. The system first allocates a pre-defined set of i-th candidate communication resources to the device. This set of resources is configured based on the device's basic type or general standards, aiming to provide the minimum resources required for device startup and initial operation. Next, the system performs a functional test on the device to check if it can operate normally under the current resource configuration. If the device operates normally, it indicates that the initially allocated resources are sufficient to support the device's basic functions. The system then retains this resource configuration as a candidate communication resource suitable for the device. However, if the device experiences operational anomalies, such as initialization failure or functional limitations, the system recognizes the inadequacy of the initially allocated resources and attempts to allocate more resources (i+1-th candidate communication resources) and tests again. This incremental, cyclically increasing approach allows the server to gradually increase the resource allocation until the optimal resource configuration for normal device operation is found.

[0075] Example 3:

[0076] Suppose that during the server's POST process, a new model of DPU (Data Processing Unit) is discovered. However, because its device ID and vendor ID are not yet entered into the current resource configuration table, the system cannot directly identify its resource requirements. In this case, the system will allocate a basic first-line candidate communication resource set based on the DPU's general requirements, including a certain bus bandwidth and a small MMIO area. Subsequently, the server starts the DPU through the BIOS program, running small tasks involving network packet processing and data acceleration. If the DPU can successfully handle these tasks, it indicates that the initially allocated resources are sufficient, and the system will save these resource configurations as valid communication resources for the DPU. Conversely, if the DPU exhibits abnormalities such as high latency, packet loss, or data processing errors while processing tasks, the system will recognize the resource insufficiency and subsequently allocate a second-line candidate communication resource, increasing the bus bandwidth and MMIO space size. The system will then retest the DPU's operation. This process will continue iteratively until the optimal resource configuration that meets the DPU's functional requirements is found.

[0077] Through the above-described embodiments of this application, the server can intelligently adapt to the addition of new devices, which not only ensures the normal operation of the devices, but also accumulates valuable experience data for future resource management and device support, thereby improving the overall flexibility and efficiency of the server.

[0078] In an optional implementation, after marking the second component as the third component, if at least one first component does not include the second component that has not been allocated communication resources, the server currently has unallocated communication resources; the unallocated communication resources are divided equally according to the number of at least one first component, and the equally divided unallocated communication resources are allocated to the first components.

[0079] It's important to explain how the remaining unallocated communication resources are handled after allocating communication resources to all pluggable devices during server startup to achieve efficient resource utilization and rational allocation. First, the system checks if there are any unprocessed pluggable devices. If there are no unprocessed devices, it means that all pluggable devices have been allocated the necessary communication resources, and the system then tallies the remaining unallocated communication resources. Next, based on the number of processed components (pluggable devices) on the server, the system equally distributes the remaining communication resources to enhance the communication capabilities of each device or reserve space for future device expansion.

[0080] In an optional implementation, allocating communication resources to all pluggable devices is a crucial step in the resource management process during the server's POST phase. Once the system determines that all second components have been processed (i.e., marked as third components), the initial resource allocation is complete, and the next steps focus on optimizing the allocation of remaining communication resources. This step not only improves the performance of existing devices but also provides a foundation for future device expansion, ensuring the flexibility and scalability of the server architecture. The system first determines the total amount of currently unallocated communication resources on the server, and then distributes these resources equally based on the number of at least one first component (processed pluggable devices). This equal distribution strategy takes into account that the server may be configured with multiple pluggable devices of the same or different types. By equally distributing unallocated resources, it ensures that each device has the opportunity to obtain additional resources, improving its communication and data processing capabilities. It is worth noting that this resource allocation method does not allocate all remaining resources at once but dynamically adjusts them according to the actual number and needs of the devices, aiming to achieve optimal resource allocation and avoid resource waste.

[0081] In an optional implementation, after marking all pluggable devices in the server as third components, the system performs a resource statistic to determine the total amount of remaining unallocated communication resources. Subsequently, the system distributes the remaining resources proportionally based on the number of processed devices (first components), ensuring that each device receives an equal amount of additional resources. This process can be implemented through the resource management module in the BIOS program, which dynamically calculates the resource allocation ratio and applies it to the actual resource allocation. After the resource allocation strategy is determined, the BIOS program sets the allocated communication resources in the registers of the relevant hardware according to the device type and location. For example, for bus bandwidth allocation, the program modifies the configuration registers of the bus controller to ensure the new bus allocation scheme takes effect. For MMIO region allocation, the program modifies the memory mapping registers, allocates a new MMIO address space, and informs the devices how to access these regions. After resource allocation is complete, the system needs to update the resource status to reflect the latest resource layout. This typically involves updating the Fabric resource data in the EEPROM, recording the latest resource allocation for each device, and providing data support for quickly restoring the resource layout upon the next server startup.

[0082] Example 4:

[0083] Assuming the server boots during the POST phase, the BIOS and BMC, working together, have identified and allocated necessary communication resources, including bus resources and MMIO resources, to all pluggable devices (such as GPUs, DPUs, and CXL memory expansion modules). At this point, the system detects no unprocessed pluggable devices, meaning the second component has been fully marked as the third component. Next, the BIOS begins to assess the server's currently unallocated communication resources, finding that 10% of the bus bandwidth and some unused MMIO address space remain unoccupied. The server is currently configured with four pluggable devices: two GPUs, one DPU network processor, and one CXL memory expansion module. Based on the number and type of these devices, the BIOS decides to allocate the remaining 10% of the bus bandwidth equally to these four devices, while allocating the unused MMIO address space as needed, prioritizing devices with higher MMIO requirements such as the GPU and DPU. After resource allocation, the BIOS updates the Fabric resource data in the EEPROM, recording the new resource layout. For example, the bus bandwidth of each GPU accelerator card is increased by 2.5% (i.e., 10% / 4) on the original basis, and the DPU network processor and CXL memory expansion module are also increased accordingly. At the same time, the MMIO region mapping is adjusted to ensure that each device has sufficient resources for efficient communication and data processing.

[0084] Through the above-described embodiments of this application, the server can maximize the utilization of system resources and improve overall computing power without sacrificing stability, while reserving space for possible future device expansion and performance upgrades. This resource management mechanism reflects the pursuit of resource utilization efficiency and system flexibility in modern server architecture and is an important means of achieving high-performance computing and data center optimization.

[0085] In an optional implementation, when the server includes at least one first component, before determining the processing state corresponding to each of the at least one first component, the method includes: determining reference device information corresponding to each of the at least one fourth component included in the server, wherein the fourth component is an onboard device; determining fixed communication resources corresponding to each of the at least one fourth component based on the reference device information corresponding to each of the at least one fourth component, and allocating corresponding fixed communication resources to the fourth component.

[0086] It should be noted that the fourth component refers to onboard devices within the server. These devices are directly integrated onto the server motherboard and are not removable. Due to their fixed location, their functions and communication requirements are determined during the server design phase. Reference device information describes the characteristics of onboard devices, such as device type, model, and manufacturer ID, and serves as the basis for determining the fixed communication resource requirements of these devices. Fixed communication resources refer to communication resources specifically pre-configured for onboard devices, such as bus resources, MMIO areas, and port I / O. These resources are allocated when the server starts up and do not change with environmental variations.

[0087] In an optional implementation, handling the allocation of communication resources for onboard devices is a crucial first step in the server initialization and resource allocation process. Unlike pluggable devices, which may bring about changes in resource requirements, the configuration and functional requirements of onboard devices are fixed. Therefore, the server prioritizes processing onboard devices during the POST startup phase. By collecting and analyzing reference device information for each onboard device, the system can quickly determine their required fixed communication resources and allocate them immediately. This strategy of pre-processing onboard devices not only simplifies the resource allocation process and avoids unnecessary delays but also provides a more accurate and stable device information and resource layout background for subsequent dynamic resource allocation to pluggable devices. Furthermore, since the resource requirements of onboard devices are determined during the design phase, this allocation method ensures optimal resource utilization and avoids resource waste or uneven allocation.

[0088] In an optional implementation, during the POST (Post-Processing) phase of server startup, the BIOS program actively scans the onboard devices on the motherboard and collects reference device information for each device. This information includes the device type, model, and vendor ID, used for subsequent resource allocation decisions. After collecting the reference device information, the system determines the fixed communication resources required by each onboard device based on this information and a preset resource allocation table. For example, for a UMC memory controller integrated on the motherboard, the system determines the required MMIO region size and bus bandwidth based on its device type and functional requirements. After determining the fixed communication resource requirements of each onboard device, the BIOS program immediately performs resource allocation, modifying the register settings of the relevant hardware to allocate or preset the required communication resources. For example, for devices requiring a fixed MMIO region, the program modifies the memory mapping registers to ensure that the device can access the predetermined MMIO address space. After allocating resources, the BIOS program updates the Fabric resource data in the EEPROM, recording the latest resource allocation status of each onboard device. This information is used in the subsequent system startup process to ensure that the resource allocation status of the onboard devices can be quickly restored without needing to make resource allocation decisions again.

[0089] Through the above-described embodiments of this application, this resource allocation process for onboard devices not only demonstrates the intelligence and efficiency of the server in resource management but also ensures the compatibility and stability of the server equipment. By meeting the resource requirements of onboard devices during the initialization phase, the server can enter a working state more quickly, improving startup speed and response performance, which has significant practical implications for data centers and high-performance computing environments.

[0090] In an optional implementation, after obtaining the status of each component of the server, the process includes: comparing the current status of each component of the server with a reference configuration of the server, wherein the reference configuration is the configuration when the server was last powered on; if the current status of each component of the server differs from the reference configuration of the server, allocating communication resources to each component of the server based on the device information corresponding to at least one first component and at least one fourth component; and, after completing the allocation of communication resources to each component of the server, recording the allocation result of communication resources to each component of the server in a resource management register.

[0091] It should be noted that the reference configuration refers to the hardware configuration state of the server at the time of its last boot, including the type, quantity, and location of each component. This configuration is used to compare the server with the current configuration during the current boot to determine whether communication resources need to be reallocated. The resource management register is a hardware register in the server used to record and manage the Fabric resource allocation state. It stores the communication resource allocation results for all devices, including onboard devices (the fourth component) and pluggable devices (the first component), which helps in quickly restoring and managing resource states.

[0092] The BIOS program reads the server's current hardware configuration and compares it with the reference configuration from the last boot. If a configuration change is detected, such as the insertion of a new GPU accelerator card or DPU network processor, or the removal of certain devices, the BIOS initiates a dynamic resource allocation algorithm to reallocate Fabric resources based on the current hardware configuration. This reallocation process involves analyzing device information for all server components, including onboard devices (the fourth component) and pluggable devices (the first component), to determine the communication resources required by each device. Once this process is complete, the BIOS records the new communication resource allocation results in the resource management register, ensuring the system can quickly access and maintain this information for rapid restoration of the resource layout upon the next boot.

[0093] In an optional implementation, resource management during server startup is a dynamic and complex process. After initializing the kernel and cache, and establishing the IPMI communication link, the BIOS program enters a state comparison and resource allocation decision-making phase. The main goal of this phase is to ensure that changes in the server's hardware configuration are identified in a timely manner and that communication resource allocation is intelligently adjusted based on the changes to meet the normal operation requirements of all devices. If the server's current hardware configuration differs from the previous configuration, the BIOS will initiate a dynamic resource allocation algorithm. This algorithm determines the optimal communication resource configuration for each device based on device information, including device type, model, vendor ID, and the current hardware topology. For newly inserted devices, the algorithm allocates necessary communication resources based on their device information and preset resource requirements. For removed devices, the algorithm releases the resources they previously occupied for use by other devices or as backup resources. After resource allocation is completed, the BIOS updates the data in the resource management register, recording the latest communication resource allocation for each device. This information update not only helps the server quickly complete resource allocation during this startup, but also allows the BIOS to directly read the information in the resource management registers upon the next server startup, skipping the resource allocation decision-making process and significantly improving startup speed and resource management efficiency. Simultaneously, this mechanism also supports flexible resource adjustment and intelligent management, ensuring that the server maintains high performance and stability when facing diverse and changing hardware environments.

[0094] After the server boots up, the BIOS program reads the current hardware configuration status, including the type, quantity, and location information of CPU cores, onboard devices, and pluggable devices. It then compares this information with the reference configuration from the last boot, identifying configuration differences such as the insertion of new devices or the removal of old devices. Once a hardware configuration change is detected, the BIOS initiates a dynamic resource allocation algorithm. This algorithm recalculates resource allocation based on the device information of each device and the existing resource layout. For new devices, the algorithm searches for their type in the resource configuration table, determines the corresponding resource requirements, and allocates or creates these resources in the system. If the device type is not in the table, the algorithm uses a default or tiered allocation strategy for initial resource allocation. After resource allocation is complete, the BIOS updates the information in the resource management register, storing the communication resource allocation results for all devices under this configuration. This includes detailed information on allocated bus bandwidth, MMIO areas, port I / O, and other resources, as well as the resource usage status of each device. The BIOS also backs up the communication resource allocation results to the BMC's EEPROM, ensuring that resource allocation information is preserved even in the event of an unexpected power outage. This backup information will be read the next time the server boots up. If the configuration has not changed, the BIOS can directly restore the resource layout state from the EEPROM, avoiding repeated calculations of resource allocation and improving boot efficiency.

[0095] Through the above-described embodiments of this application, the server can intelligently respond to changes in hardware configuration, ensuring that all devices can obtain communication resources that meet their needs, thereby providing a foundation for the server's efficient operation and stability. Simultaneously, the updates to information in the resource management register and BMC EEPROM enable the server to maintain efficient and accurate resource allocation in environments with frequent hardware changes, reducing the computational cost of repetitive resource allocation and improving the overall performance and management efficiency of the server.

[0096] In an optional implementation, after comparing the current components of the server with the reference configuration of the server, the process includes: if the current components of the server are the same as the reference configuration of the server, reading a reference communication resource allocation result from a resource management register, wherein the reference communication resource allocation result is used to indicate the communication resource allocation result corresponding to the reference configuration; and allocating communication resources to the current components of the server according to the reference communication resource allocation result.

[0097] It should be noted that the reference communication resource allocation result refers to the communication resource allocation scheme determined by the server during the previous startup based on the hardware configuration at that time (reference configuration), which is stored in the resource management register to guide the server's resource allocation decision during this startup.

[0098] The BIOS program compares the current state of each component of the server with the reference configuration from the last boot. Once the two are consistent, it directly reads the previous reference communication resource allocation result from the resource management register and uses this as the basis for the current boot, allocating the same communication resources to all devices on the server. This strategy not only improves the server's boot speed but also ensures the consistency and stability of resource allocation, avoiding unnecessary resource reallocation processes.

[0099] In optional implementations, resource management is a crucial aspect of server startup, particularly during the POST (Power-On Self-Propagation) phase. When the system detects that the current hardware configuration is identical to that of the previous boot—meaning no new, removed, or replaced server components—the BIOS program employs a more efficient resource allocation method. It reads the previous reference communication resource allocation result from the resource management register. This result contains details of the communication resource allocation for all devices, such as bus bandwidth, MMIO area, and port I / O. Based on this result, the BIOS quickly allocates the same communication resources to all devices without re-executing resource detection and dynamic allocation algorithms, significantly saving time and improving startup efficiency. Simultaneously, this ensures consistent resource allocation under the same hardware configuration, contributing to the stability and predictability of server operation—a smart practice in modern server resource management.

[0100] During the POST (Power-On Post-Processing) phase, the BIOS program first reads the current status of each component of the server, including the type, quantity, and location information of the CPU, onboard devices, and pluggable devices. Then, the program compares the current hardware configuration with the reference configuration stored in the EEPROM from the last boot. If they are identical, it indicates that the hardware configuration has not changed. After confirming that the configuration has not changed, the BIOS reads the previous reference communication resource allocation result from the resource management register. This result details the communication resource allocation for each device, including bus resources, MMIO areas, and port I / O. With the historical reference communication resource allocation result, the BIOS program no longer needs to perform time-consuming resource detection and dynamic allocation processes; instead, it directly allocates communication resources to each component of the server based on this result, ensuring rapid and accurate resource allocation. After resource allocation is complete, the system updates the Fabric resource data in the EEPROM, recording the result of this resource allocation, providing data support for quickly identifying and applying the resource allocation scheme during the next server startup.

[0101] Example 5:

[0102] Suppose that the server's configuration at its last boot included two CPUs, one GPU, and one DPU network processor. After a power outage and restart, the BIOS program initializes and reads the current hardware status, finding that the hardware configuration is exactly the same as at the last boot, with no added, removed, or replaced devices. In this case, the BIOS program does not initiate resource probing and dynamic allocation algorithms; instead, it directly reads the previous reference communication resource allocation results from the resource management registers. For example, the reference results indicate that the bus bandwidth previously allocated to the two CPUs was 20% and 30%, respectively, the GPU had a 512MB MMIO region, and the DPU network processor used specific port I / O resources. Based on this historical allocation result, the BIOS program quickly allocates the same communication resources to all devices on the server without additional resource probing and calculations. After allocation, the BIOS updates the Fabric resource data in the EEPROM, recording the resource allocation details to ensure this information is saved and quickly retrieved during future boots, achieving efficient and consistent resource management.

[0103] Through the above-described embodiments of this application, the server can significantly shorten startup time in startup scenarios without hardware changes, while maintaining the accuracy and stability of resource allocation, thus helping to improve the daily operational efficiency and user experience of the server. This intelligent resource allocation strategy based on historical data is an advanced practice in the field of server management, especially in large-scale data center environments, where it can significantly improve resource management efficiency and reduce maintenance costs.

[0104] In an optional implementation, reading the reference communication resource allocation result from the resource management register includes: verifying the reference communication resource allocation result; and if the verification of the reference communication resource allocation result fails or reading the reference communication resource allocation result from the resource management register fails, allocating resources to the current components of the server according to the candidate communication resource allocation result.

[0105] The verification of the reference communication resource allocation results includes at least one of the following:

[0106] 1) Read the header data of the reference communication resource allocation result, determine the data category of the reference communication resource, and if the data category is not communication resource data, determine that the reference communication resource allocation result has failed the verification;

[0107] 2) Calculate the first check code based on the reference communication resource and read the second check code from the reference communication resource. If the first check code and the second check code are inconsistent, determine that the allocation result of the reference communication resource has failed the verification.

[0108] 3) Read the first model from the reference communication resource allocation result and determine the second model of the server. If the first model and the second model are inconsistent, determine that the reference communication resource allocation result has failed the verification.

[0109] It should be noted that when the reference communication resource allocation result is unavailable, such as due to verification failure or reading failure, the system will allocate communication resources to the current components of the server according to predefined rules or default resource allocation strategies to ensure that the server can start and run normally.

[0110] When obtaining the reference communication resource allocation result, the BIOS program performs multiple checks on the data to ensure the validity and applicability of the result. If the check fails or the data reading itself fails, the BIOS will allocate resources according to the candidate communication resource allocation result to ensure stable server operation. The verification process includes data signature verification, CRC cyclic redundancy check, and machine model information matching. These three steps are independent of each other, but all aim to confirm the correctness of the data and its compatibility with the current server hardware.

[0111] In optional implementations, ensuring the reliability and applicability of communication resource allocation results is crucial during the resource allocation process in the server's POST phase. After reading the reference communication resource allocation result from the resource management register, the BIOS program performs a series of checks, including data signature verification, CRC checksum verification, and model information matching. If any check fails, or if there is a problem with the data reading itself, the system will switch to using a candidate communication resource allocation result. This result is usually based on the default configuration or the record from the previous boot, but has undergone simple preprocessing to adapt to the current server hardware state. Using candidate communication resource allocation results not only ensures the stable operation of the server but also provides a reliable fallback strategy when the reference data becomes invalid for various reasons, ensuring that the server does not fail to start due to resource allocation problems. Furthermore, this mechanism also reflects the flexibility of server resource management, enabling flexible adjustment of resource allocation strategies in the face of data anomalies or hardware changes to meet the needs of normal server operation.

[0112] In an optional implementation, the BIOS program attempts to read the reference communication resource allocation result from the resource management register and immediately initiates the verification process.

[0113] Verification Process: First, read the data header information to ensure its signature conforms to the standard format of Fabric resource data; this is a preliminary confirmation of the data category. Calculate the CRC checksum of the reference communication resource allocation result and compare it with the CRC code stored in the data to confirm data integrity and tamper-proofing. Read the machine model information contained in the reference communication resource allocation result and compare it with the current server model to ensure the allocation scheme is suitable for the current hardware environment.

[0114] If a problem is found in any verification step, such as a data signature mismatch, CRC check failure, or model information mismatch, the BIOS will determine that the reference communication resource allocation result has failed verification. In the event of a failure to verify or read the reference communication resource allocation result, the BIOS will use the candidate communication resource allocation result to allocate resources, ensuring the server can boot and run successfully. The candidate communication resource allocation result is based on the default configuration or the resource allocation record from the previous successful boot. The BIOS will adjust the candidate communication resources appropriately according to the specific configuration of the current server hardware to adapt to the current hardware environment. If a new device is added to the server, the BIOS will estimate and allocate certain temporary communication resources to the new device for basic boot and testing. Based on the selected communication resource allocation result, the BIOS will set the relevant hardware registers and allocate corresponding bus resources, MMIO areas, port I / O, etc., ensuring that all devices can obtain the necessary communication resources. After completing the resource allocation, the BIOS will store this result in the BMC's EEPROM as a reference configuration for the next boot.

[0115] Figure 3 This is a schematic diagram of an optional resource data according to an embodiment of this application; as shown... Figure 3 As shown, the Fabric resource data protocol framework is designed to optimize the efficiency of data storage and interaction between the host unit (i.e., the main computing unit of the server) and the BMC unit (Baseboard Management Controller), while ensuring data integrity and relevance. The protocol organizes data into two main parts: Header information and Data information. Each part carries specific functions to support efficient resource management and configuration.

[0116] Header information section:

[0117] Signature (0x00-0x03): This is a fixed 4-byte signature field used to identify whether data belongs to a Fabric resource. Its value is "FABR", ensuring that the host unit can immediately recognize that the data is associated with a Fabric resource when reading it.

[0118] Version (0x04-0x05): Contains 8-bit version number information, divided into major version number and minor version number, used to track and manage different versions of Fabric resource data, ensuring compatibility and a smooth transition of updates.

[0119] Total Length (0x06-0x07): This 8-bit field indicates the total length of the entire data packet (Header + Data). The host unit uses this information to determine the range of valid data, avoiding reading invalid or out-of-range data and improving processing efficiency.

[0120] CRC32 (0x08-0x0B): Includes a 32-bit CRC32 checksum used to verify the integrity of Fabric resource data. After reading the data, the host unit recalculates the CRC code and compares it with the stored CRC code. If they match, the data passes the integrity check; otherwise, it indicates that the data may have been damaged during transmission or storage and cannot be used for resource allocation.

[0121] Data Start Address (0x0C-0x0D): This 16-bit field records the starting storage address of the Data portion, providing the host unit with a clue as to where to begin reading data information.

[0122] Data Length (0x0E-0x0F): A 16-bit field indicating the size of the Data section. Combined with the starting address information, the host unit can accurately locate and read the entire contents of the Data section.

[0123] Model (0x10-0x1F): Contains 16 bytes of model information, identifying which specific server model this set of Fabric resource data is designed for. The host unit checks this information to ensure the data matches the current server's model, and then decides whether to use this set of data for resource configuration.

[0124] Data information section:

[0125] Each data unit occupies a fixed 32 bits of space, used to describe specific Fabric resource configuration details. Taking the first unit, Resources[0], as an example:

[0126] CPU ID (0x20): An 8-bit field that encodes a unique identifier for a CPU in the system, making it easier for the host unit to accurately locate the target CPU when allocating resources.

[0127] Module ID (0x21): Further subdivided into 8 bits, specifically indicating the module number inside a particular CPU, further improving the accuracy of resource allocation.

[0128] Type (0x22): An 8-bit type encoding field used to distinguish different Fabric resource types, such as PCI configuration space resources (encoded as 00), MMIO resources (encoded as 01), port IO resources (encoded as 02), memory-mapped resources (encoded as 03), etc.

[0129] Flag (0x23): Another 8-bit field used to mark certain attributes or configuration logic of the resource, such as whether the MMIO resource supports prefetching, access width, etc., to provide more detailed resource usage guidance for the host unit.

[0130] Value (0x24-0x27): The last 32-bit field carries the specific numerical value or configuration information of the resource. Its interpretation depends on the values ​​of the Type and Flag fields, allowing the host unit to correctly use this information based on the resource type and attributes.

[0131] In an optional implementation, after the server completes resource allocation during the POST phase, the BIOS program generates a new set of Fabric resource data, according to... Figure 3 The format shown is stored in the BMC's EEPROM to ensure data persistence and accessibility. The host unit reads this data during subsequent startup, first verifying the Signature, CRC, and Model information to confirm the data's validity and applicability. After determining the location and length of the Data section using the Header information, the host unit sequentially parses the CPU ID, Module ID, Type, Flag, and Value information of each unit. Based on this data, it sets the Fabric-related hardware registers, completing resource allocation and configuration.

[0132] Example 6:

[0133] During server startup, the host unit reads Fabric resource data from the BMC's EEPROM. First, it verifies that the Signature is "FABR" to confirm that the data packet is Fabric resource data. Next, the host unit checks the CRC information and ensures the integrity of the data by comparing it with its own recalculated CRC value. At the same time, it also compares the model information in the Model field to ensure that the data is applicable to the current server model. Subsequently, the host unit begins to parse the first unit of the Data section, Resources[0]. It reads the CPU ID field to determine the target CPU for resource allocation; then it decodes the Module ID to locate the specific module within the CPU; the Type field gives the type of resource, such as if it is found to be an MMIO resource (encoded 01); the Flag field may indicate the prefetch attributes and access width of the MMIO resource; finally, the Value field provides the specific address and size information of the MMIO resource. Based on the parsed Type and Value information, the host unit correctly sets the registers of the target CPU and module, allocates the corresponding MMIO address and size, and completes the resource configuration. This fine organization method not only ensures efficient storage and retrieval of data, but also provides solid underlying data support for flexible resource allocation and improves the intelligence level of server resource management.

[0134] Through the above-described implementation method of this application, after resource allocation is completed, the BIOS updates the Fabric resource data in the EEPROM and records the candidate communication resource allocation results. This allows the system to quickly switch to the stored candidate allocation scheme if the reference data fails to verify or encounters other problems during the next server startup, ensuring high availability and fast startup characteristics of the server. This mechanism not only improves server management efficiency but also enhances its adaptability and stability in complex and ever-changing operating environments.

[0135] Figure 4 This is a schematic diagram of an optional communication resource allocation method according to an embodiment of this application; as shown... Figure 4 As shown, controller 104 can be a BMC (Baseboard Management Controller) unit, which plays a key role in the server hardware architecture. It is mainly responsible for receiving, storing, and maintaining Fabric resource data, and providing data query interfaces to the inside and outside of the system. Its functions are implemented based on the initialization and management of the EEPROM chip and the construction of the IPMI interface service.

[0136] In an optional implementation, when the server powers on, the BMC processing core first initializes the EEPROM (Electrically Erasable Programmable Read-Only Memory) chip to ensure read and write operations are possible. Simultaneously, a contiguous space is reserved within the EEPROM chip specifically for storing Fabric resource data. This space is protected by a "space barrier," employing a special access control mechanism to prevent other data from overflowing into this area, thus avoiding compromise to the integrity and security of the Fabric resource data. Furthermore, the space barrier prevents unauthorized programs from illegally reading or writing to this area, ensuring the confidentiality of the Fabric resource data and preventing malicious tampering, thereby enhancing server security. The BMC processing core further initializes the IPMI (Intelligent Platform Management Interface) service. This service supports IPMI commands customized by OEMs (Original Equipment Manufacturers), allowing host units to query Fabric resource data using these commands. The establishment of the IPMI interface service provides out-of-band management capabilities for the server; even if the host fails or becomes inaccessible, administrators can still monitor, maintain, and query resource data through the IPMI interface. After initialization, the BMC unit enters the working state, ready to respond to external requests to read and write Fabric resource data, including read and write requests from the host unit. This means that the host unit or other authorized components can query, update, or verify Fabric resource data in real time, thereby enabling dynamic management and optimization of server resources.

[0137] The Fabric Resource Management (BMC) unit plays an indispensable role in server resource management. It not only stores crucial Fabric resource data but also provides a real-time data access interface, enabling dynamic monitoring and management of resources. By initializing the EEPROM chip and IPMI interface service, the BMC unit ensures that the server obtains accurate resource information during the POST phase, thus providing a solid foundation for stable system operation. Furthermore, the BMC unit's real-time responsiveness allows it to support the server's dynamic resource adjustment needs. Even during operation, it can update Fabric resource data promptly based on changes in system status, ensuring optimal resource allocation and continuous improvement in system performance. This mechanism greatly enhances the server's flexibility and manageability, making it an indispensable part of modern server architecture.

[0138] Figure 5 This is a flowchart of another optional method for allocating communication resources according to an embodiment of this application; as shown... Figure 5 As shown, step S502 initializes the environment, then step S504 determines whether the configuration has changed. If not, step S506-1 retrieves data from the resource configuration table, and step S508 checks if the resource acquisition and verification were successful. If verification fails, step S512-1 allocates resources according to fixed logic. If changes have occurred, step S506-2 clears the data from the resource configuration table, and step S510 performs the dynamic resource allocation process described above to determine the target configuration. Finally, step S512-2 applies the corresponding configuration.

[0139] Based on the above-mentioned automatic Fabric resource configuration method in the POST phase, deep learning technology and adaptive adjustment mechanism are further introduced. By monitoring the server's running status in real time, Fabric resource allocation is dynamically adjusted to meet the changing load requirements in real time, while optimizing server performance and resource utilization efficiency.

[0140] In an optional implementation, a deep learning model is developed to predict resource requirements under different server loads. The model will learn the server's resource consumption characteristics in different application scenarios based on historical operational data, including CPU utilization, network traffic, and memory access patterns. A real-time monitoring module is integrated into the system to continuously monitor the server's operating status and load changes. Monitoring data will be analyzed in real time to assess whether the current resource allocation meets the server's performance requirements. An adaptive algorithm is designed to dynamically adjust the allocation of Fabric resources based on real-time monitoring data and predictions from the deep learning model. For example, the algorithm can automatically increase the GPU's MMIO resources to improve the performance of graphics processing or AI acceleration tasks; or optimize the DPU's data processing bus resources to enhance network processing capabilities. An intelligent feedback loop is established, enabling the system to continuously optimize resource allocation strategies based on the effects of adjustments. If the adjusted resource allocation improves server response speed or reduces latency, the algorithm will record these optimizations and apply them in subsequent resource allocations. Through integration with the BMC unit, administrators can remotely update the parameters of the deep learning model and adaptive adjustment algorithm via the IPMI interface to respond to changes in the server environment or new application requirements. This allows resource allocation strategies to dynamically adapt to changes in data center operational strategies, optimizing server performance.

[0141] Historical runtime data is collected within the server cluster to train deep learning models. Once trained, the model is deployed to the server's BIOS as an auxiliary tool for resource allocation decisions. During server operation, runtime status data is collected via the CPU, PMI hardware path, and IPMI interface. The BMC unit transmits this data to the BIOS in real time, serving as input for model prediction and resource adjustment algorithms. Based on model predictions and real-time load conditions, the BIOS dynamically adjusts Fabric resource allocation, such as expanding or shrinking bus resources for specific devices, adjusting the size of the MMIO region, and optimizing memory access paths. After resource allocation adjustments, the system monitors performance changes, including key metrics such as processing speed, latency, and power consumption. If performance improves, the adjustment strategy is recorded for subsequent resource allocation decisions; if performance degrades, the algorithm automatically reverts to the original configuration or seeks a better adjustment scheme. Administrators can remotely monitor server resource allocation status and performance through the data center management platform, updating model parameters or algorithm strategies as needed to adapt to new operating environments or application requirements.

[0142] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0143] Embodiments of this application also provide a communication resource allocation device. Figure 6 This is a structural block diagram of an optional communication resource allocation device according to an embodiment of this application, such as... Figure 6 As shown, the device includes:

[0144] The status acquisition module 602 is used to acquire the status of various components of the server when the server is powered on.

[0145] The component status determination module 604 is used to determine the processing status of each of the at least one first component when the server includes at least one first component, wherein the first component is a pluggable device and the processing status is used to indicate whether the first component performs communication resource allocation.

[0146] Resource determination module 606 is used to determine the target communication resource corresponding to the second component in the resource configuration table by using the device information of the second component when at least one first component includes a second component for which no communication resource allocation has been performed.

[0147] The resource allocation module 608 is used to configure the target communication resources corresponding to the second component and mark the second component as the third component, wherein the third component is the first component that has been allocated communication resources.

[0148] Optionally, the resource determination module 606 is further configured to: read the device information of the second component, wherein the device information is used to indicate the device type and production identifier of the second component; query the interaction interface of the second component based on the device information of the second component; allocate reference communication resources to the second component if the interaction interface defines reference communication resources, and mark the second component as a third component.

[0149] Optionally, the resource determination module 606 is further configured to: when no reference communication resource is defined in the interaction interface, search for a communication resource matching the device information in the resource configuration table using the device information of the second component; when no communication resource matching the device information is found in the resource configuration table, allocate a candidate communication resource to the second component; and when a communication resource matching the device information is found in the resource configuration table, determine the communication resource matching the device information as the target communication resource.

[0150] Optionally, the resource determination module 606 is further configured to: allocate the i-th candidate communication resource to the second component and test the second component; determine the i-th candidate communication resource as a candidate communication resource when the second component is operating normally; allocate the (i+1)-th candidate communication resource to the second component when the second component is operating abnormally, and determine the (i+1)-th candidate communication resource as a candidate communication resource when the second component is operating normally.

[0151] Optionally, the resource allocation module 608 is further configured to: determine the currently unallocated communication resources of the server when at least one first component does not include a second component that has not been allocated communication resources; divide the unallocated communication resources equally according to the number of at least one first component, and allocate the equally divided unallocated communication resources to the first component.

[0152] Optionally, the component status determination module 604 is further configured to: determine reference device information corresponding to each of the at least one fourth component included in the server, wherein the fourth component is an onboard device; determine fixed communication resources corresponding to each of the at least one fourth component based on the reference device information corresponding to each of the at least one fourth component, and allocate corresponding fixed communication resources to the fourth component.

[0153] Optionally, the aforementioned status acquisition module 602 is further configured to: compare the current components of the server with the server's reference configuration, wherein the reference configuration is the configuration of the server when it was last powered on; if the current components of the server differ from the server's reference configuration, allocate communication resources to the current components of the server based on the device information corresponding to at least one first component and at least one fourth component; and, upon completion of the allocation of communication resources to the current components of the server, record the allocation results of the communication resources to the current components of the server in the resource management register.

[0154] Optionally, the aforementioned status acquisition module 602 is further configured to: read reference communication resource allocation results from the resource management register when the current components of the server are the same as the reference configuration of the server, wherein the reference communication resource allocation results are used to indicate the communication resource allocation results corresponding to the reference configuration; and allocate communication resources to the current components of the server according to the reference communication resource allocation results.

[0155] Optionally, the aforementioned status acquisition module 602 is further configured to: verify the reference communication resource allocation result; in the event that the verification of the reference communication resource allocation result fails or the reading of the reference communication resource allocation result from the resource management register fails, allocate the current components of the server according to the candidate communication resource allocation result; wherein, verifying the reference communication resource allocation result includes at least one of the following: reading the header data of the reference communication resource allocation result, determining the data category of the reference communication resource, and determining that the reference communication resource allocation result has failed verification if the data category is not communication resource data; calculating a first verification code based on the reference communication resource, and reading a second verification code from the reference communication resource, and determining that the reference communication resource allocation result has failed verification if the first verification code and the second verification code are inconsistent; reading a first model from the reference communication resource allocation result, and determining a second model of the server, and determining that the reference communication resource allocation result has failed verification if the first model and the second model are inconsistent.

[0156] For a description of the features in the embodiment corresponding to the communication resource allocation device, please refer to the relevant description in the embodiment corresponding to the communication resource allocation method, which will not be repeated here.

[0157] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the communication resource allocation method.

[0158] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described communication resource allocation method embodiments when it runs.

[0159] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0160] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described communication resource allocation method embodiments.

[0161] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described communication resource allocation method embodiments.

[0162] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0163] The foregoing has provided a detailed description of a communication resource allocation method and apparatus, storage medium, and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for allocating communication resources, comprising: obtaining states of components of a server when the server is powered on; determining respective processing states of at least one first component corresponding to the at least one first component, wherein the first component is a pluggable device, and the processing state indicates whether the first component has performed the allocation of the communication resources; determining a target communication resource corresponding to a second component in a resource configuration table using device information of the second component, wherein the second component is a component that has not performed the allocation of the communication resources; configuring the target communication resource corresponding to the second component for the second component, and marking the second component as a third component, wherein the third component is the first component that has performed the allocation of the communication resources; and wherein the determining the target communication resource corresponding to the second component in the resource configuration table using the device information of the second component comprises: allocating an ith candidate communication resource for the second component and testing the second component when no communication resource matching the device information is found in the resource configuration table, wherein the second component corresponding to the communication resource not found in the resource configuration table is a pluggable device that has not been identified or processed before; determining the ith candidate communication resource as the candidate communication resource when the second component operates normally; and allocating an (i+1)th candidate communication resource for the second component and determining the (i+1)th candidate communication resource as the candidate communication resource when the second component operates normally.

2. The method of claim 1, wherein, before the determining the target communication resource corresponding to the second component in the resource configuration table using the device information of the second component, the method further comprises: reading the device information of the second component, wherein the device information indicates a device type and a production identification of the second component; querying an interaction interface of the second component according to the device information of the second component; and allocating a reference communication resource for the second component and marking the second component as the third component when the interaction interface defines the reference communication resource.

3. The method of claim 2, wherein the determining the target communication resource corresponding to the second component in the resource configuration table using the device information of the second component comprises: searching for a communication resource matching the device information in the resource configuration table using the device information of the second component when the interaction interface does not define the reference communication resource; allocating a candidate communication resource for the second component when no communication resource matching the device information is found in the resource configuration table; and determining a communication resource matching the device information as the target communication resource when the communication resource matching the device information is found in the resource configuration table.

4. The method of any one of claims 1 to 3, wherein ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ After the second component is marked as a third component, the method comprises: In the case that the at least one first component does not include a second component which has not been allocated with communication resources, determining that the server has no currently unallocated communication resources; allocating the unallocated communication resources equally according to the number of the at least one first component, and allocating the equally allocated unallocated communication resources to the first components.

5. The method of any one of claims 1 to 3, wherein, before determining the respective processing states of the at least one first component included in the server, the method comprises: determining respective reference device information of at least one fourth component included in the server, wherein the fourth component is an on-board device; determining respective fixed communication resources of the at least one fourth component according to the respective reference device information of the at least one fourth component, and allocating the respective fixed communication resources to the fourth components.

6. The method of claim 5, wherein, after obtaining the states of the components of the server, the method comprises: comparing the current components of the server with a reference configuration of the server, wherein the reference configuration is a configuration of the server at the last booting; in the case that the current components of the server are different from the reference configuration of the server, allocating communication resources to the current components of the server according to the device information of the at least one first component and the at least one fourth component; after completing the allocation of the communication resources to the current components of the server, recording the allocation results of the communication resources of the current components of the server in a resource management register.

7. The method of claim 6, wherein, after comparing the current components of the server with the reference configuration of the server, the method comprises: in the case that the current components of the server are the same as the reference configuration of the server, reading a reference communication resource allocation result from the resource management register, wherein the reference communication resource allocation result is used to indicate a communication resource allocation result corresponding to the reference configuration; allocating communication resources to the current components of the server according to the reference communication resource allocation result.

8. The method of claim 7, wherein, the reading of the reference communication resource allocation result from the resource management register comprises: verifying the reference communication resource allocation result; in the case that the verification of the reference communication resource allocation result fails or the reading of the reference communication resource allocation result from the resource management register fails, allocating the current components of the server according to a candidate communication resource allocation result; wherein, the verifying of the reference communication resource allocation result comprises at least one of the following: reading header data of the reference communication resource allocation result, determining a data category of the reference communication resource, and in the case that the data category is not communication resource data, determining that the reference communication resource allocation result fails the verification. ​ ​ ​ ​ calculating a first check code according to the reference communication resource, reading a second check code from the reference communication resource, and determining that the reference communication resource allocation result fails to pass a check in a case that the first check code and the second check code are inconsistent; reading a first model number from the reference communication resource allocation result, determining a second model number of the server, and determining that the reference communication resource allocation result fails to pass a check in a case that the first model number and the second model number are inconsistent. 9.An electronic device, comprising: a memory configured to store a computer program; a processor configured to implement the steps of the method for allocating a communication resource according to any one of claims 1 to 8 when executing the computer program. ​

Images