An accelerator management method and system based on real-time demand

Abstract

The application discloses an accelerator management method and system based on real-time demand, and the method comprises the following steps: acquiring various accelerator discovery drivers and registering the same into a database; acquiring user demand and constructing accelerator use demand with the accelerators and use modes discoverable by the accelerator discovery drivers, and storing the same into the database; an agent service on each server regularly queries the accelerator use demand created according to the user demand from the database, traverses all the accelerator use demand, matches each accelerator use demand with an appropriate accelerator discovery driver, calls the accelerator discovery driver to complete the discovery of the accelerator and the configuration of the use mode, generates a new accelerator object uploaded to a management platform; the management platform queries all the accelerator objects existing in the current database, processes the new accelerator object and the accelerator object by comparison, and updates the database.

Description

Technical Field

[0001] This invention relates to the field of accelerator management, and more specifically to an accelerator management method and system based on real-time requirements. Background Technology

[0002] As cloud computing technology matures, more and more enterprises are cloudifying their applications. However, the performance of virtual machines has been criticized. The maturity of accelerator device technology (physical devices that can be directly used by virtual machines and greatly improve their performance) has enabled most application scenarios to meet performance requirements.

[0003] Common accelerator devices include high-performance disks, network cards, graphics cards, and FPGA devices. Among these, network cards, graphics cards, and FPGAs can be used in multiple ways to meet different application scenarios. Taking Nvidia's T4 graphics card as an example, the T4 graphics card has two usage modes: passthrough and virtualization. In passthrough mode, the entire T4 graphics card is directly passed to a virtual machine. In this mode, the graphics card performance obtained by the virtual machine is almost the same as the original graphics card, but it can only be used by one virtual machine. In virtualization mode, the T4 graphics card is virtualized into five virtual graphics cards, which can be used by five virtual machines simultaneously. Each virtual machine uses one virtual graphics card, but the graphics card performance obtained by each virtual machine is only 1 / 5 of the original graphics card.

[0004] Company A currently uses T4 graphics cards for virtualization. When deploying a cloud environment for Company A, a virtualization discovery driver for the T4 graphics cards was installed (a driver that can discover the T4 graphics cards on the server and configure the usage of the T4 graphics cards as virtualization, collectively referred to as an accelerator discovery driver). However, as Company A's business changes, it needs to use the passthrough mode of T4 graphics cards. At this time, Company A needs to manually update the discovery driver of the T4 graphics cards on each server according to the cloud environment user manual. However, the user manual is very information-intensive and requires considerable professional knowledge to understand. Moreover, manual operation is cumbersome and prone to errors. In large-scale clusters (cloud environments with many servers), this method is even more inadequate for users. Summary of the Invention

[0005] The technical problem this invention aims to solve is that users cannot flexibly change the way they use accelerators in the cloud environment or add or remove accelerator types, which limits their business development. This invention provides an accelerator management method based on real-time needs, and also provides an accelerator management system based on real-time needs. This system enables driver management of accelerator discovery and configuration, completely entrusting the use and switching of accelerator discovery drivers to users. This allows users to easily change the way they use accelerators in the cloud environment at any time, so as to meet their own business needs for accelerator usage in a timely manner. This effectively improves the user experience of accelerators in the cloud environment, while reducing operation and maintenance costs, thereby solving the defects caused by existing technologies.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solutions:

[0007] Firstly, an accelerator management method based on real-time demand includes the following steps:

[0008] Step 1: Obtain various accelerator discovery drivers and register them in the database;

[0009] Step 2: Obtain user requirements, and construct accelerator usage requirements based on user requirements and the accelerators and usage methods that the accelerator discovery driver can discover, and store them in the database;

[0010] Step 3: The agent service on each server periodically queries the database for the accelerator usage requirements created based on user needs, and iterates through all accelerator usage requirements. For each accelerator usage requirement, a suitable accelerator discovery driver is matched, and the accelerator discovery driver is called to complete the discovery of the accelerator and the configuration of its usage method, generating a new accelerator object that is uploaded to the management platform.

[0011] Step 4: After receiving the new accelerator object, the management platform queries all existing accelerator objects in the current database, compares the new accelerator object with the UUID of the existing accelerator objects, deletes accelerator objects that exist in the database but are not present in the current upload, adds accelerator objects that do not exist in the database but are present in the current upload, and updates the database.

[0012] In the aforementioned accelerator management method based on real-time requirements, step 1 further requires determining whether each accelerator discovery driver is compliant, and registering the compliant accelerator discovery drivers into the database.

[0013] The above-mentioned accelerator management method based on real-time demand includes the following specific method for determining whether each accelerator discovery driver is compliant and registering the compliant accelerator discovery drivers to the database:

[0014] Step 11: The management platform obtains the accelerator discovery driver for each accelerator;

[0015] Step 12: The management platform traverses all accelerator discovery drivers in the current environment, queries all registered accelerator discovery drivers in the database, compares and determines whether each accelerator discovery driver is duplicated with all registered accelerator discovery drivers in the database, and deletes duplicate accelerator discovery drivers.

[0016] Step 13: Determine whether the names of each accelerator discovery driver are standardized, and delete accelerator discovery drivers whose names do not conform to the standard.

[0017] Step 14: Determine whether each accelerator discovery driver can implement the four sub-functions: discover, check_config_work, update_config, and support_accelerators, and delete the accelerator discovery drivers whose names cannot be implemented.

[0018] Step 15: Save the remaining accelerator discovery drivers to the database.

[0019] In the above-mentioned accelerator management method based on real-time demand, step 2 further requires determining whether the user demand is compliant, constructing the accelerator usage demand by combining the compliant user demand with the accelerators and usage methods that the accelerator discovery driver can discover, and storing it in the database.

[0020] The above-mentioned accelerator management method based on real-time demand, wherein the user demand is compliant, and the compliant user demand is combined with the accelerators that can be discovered by the accelerator discovery driver and their usage methods to construct the accelerator usage demand, and stored in the database, is specifically implemented as follows:

[0021] Step 21: The user queries the database for all registered accelerator discovery drivers and obtains information on discoverable accelerators and usage methods supported by all accelerator discovery drivers;

[0022] Step 22: If the user cannot find a supported accelerator, create a user request and send it to the management platform;

[0023] Step 23: The management platform receives the user's request, queries the database for existing accelerator usage requests, determines whether the current user's accelerator usage request is duplicated with an existing accelerator usage request, and determines whether the parameter format of the current user's accelerator usage request conforms to the specifications. If it is duplicated and does not conform to the specifications, a creation failure is reported; otherwise, the accelerator usage request is constructed based on the user's request and the discoverable accelerators and usage methods provided by the accelerator discovery driver, and stored in the database.

[0024] In the aforementioned accelerator management method based on real-time demand, step 3 is specifically as follows:

[0025] Step 31: After the agent service on each server starts, it periodically retrieves the accelerator usage requirements created based on user needs from the database;

[0026] Step 32: Iterate through all accelerator usage requirements and match a suitable accelerator discovery driver for each accelerator usage requirement;

[0027] Step 33: Determine whether the accelerator usage request is compliant based on the discoverable accelerators and usage methods provided by the accelerator discovery driver. If it is not compliant, discard the accelerator usage request and upload the error information to the log.

[0028] Step 34: The accelerator discovery driver calls the discover sub-function based on the vendor_id and product_id described in the accelerator discovery request to find accelerators on the current server whose vendor_id and product_id match.

[0029] Step 35: The accelerator discovery driver calls the check_config_work sub-function to determine whether the usage method config_type and config_info described in the accelerator requirements are consistent with the currently discovered accelerator. If they are inconsistent, proceed to step 36; if they are consistent, proceed to step 37.

[0030] Step 36: The accelerator discovery driver calls the update_config sub-function to reconfigure the accelerator's usage.

[0031] Step 37: The accelerator discovery driver generates accelerator objects and uploads them to the agent service. The agent service integrates all accelerator objects uploaded by the accelerator discovery driver and uploads them to the management platform.

[0032] Secondly, an accelerator management system based on real-time demand includes an accelerator discovery-driven registration module, an accelerator usage demand management module, a server, an accelerator discovery and configuration module, and a management platform.

[0033] The accelerator discovery driver registration module is used to acquire various accelerator discovery drivers and register them in the database.

[0034] The accelerator usage demand management module is used to obtain user demands, construct accelerator usage demands based on user demands and the accelerators and usage methods that the accelerator discovery driver can discover, and store them in the database; it is also used for users to query, create, modify, and delete accelerator usage demands in the database in real time.

[0035] The agent service on the server periodically queries the database for the accelerator usage requirements created based on user needs, and iterates through all accelerator usage requirements. The accelerator discovery and configuration module matches a suitable accelerator discovery driver for each accelerator usage requirement, calls the accelerator discovery driver to complete the discovery of the accelerator and the configuration of its usage method, and generates a new accelerator object to be uploaded to the management platform.

[0036] The management platform is used to receive the new accelerator object, query all existing accelerator objects in the current database, compare the new accelerator object with the UUID of the existing accelerator objects, delete accelerator objects that exist in the database but do not exist in the current upload, add accelerator objects that do not exist in the database but exist in the current upload, and update the database.

[0037] Thirdly, a chip comprising: a processor for retrieving and running a computer program from a memory, causing a device having the chip mounted to perform: the method as described in any one of the first aspects.

[0038] The technical solution provided by the accelerator management method and system based on real-time demand according to the present invention has the following technical effects:

[0039] By implementing driver management for accelerator discovery and configuration, the use and switching of accelerator discovery drivers are completely handed over to users. This allows users to easily change how they use accelerators in the cloud environment at any time, so as to meet their own business needs for accelerator use in a timely manner. This can effectively improve the user experience of accelerators in the cloud environment, while reducing operation and maintenance costs. Attached Figure Description

[0040] Figure 1 A flowchart of an accelerator management method based on real-time requirements;

[0041] Figure 2 This is a flowchart of step 1 in an accelerator management method based on real-time demand.

[0042] Figure 3 This is a flowchart of step 2 in an accelerator management method based on real-time demand.

[0043] Figure 4 This is a flowchart of step 3 in an accelerator management method based on real-time demand.

[0044] Figure 5 This is a schematic diagram of the structure of an accelerator management system based on real-time requirements.

[0045] The accompanying figure is labeled as follows:

[0046] Accelerator discovery driver registration module 100, accelerator usage requirement management module 200, server 300, accelerator discovery and configuration module 400, management platform 500, database 600. Detailed Implementation

[0047] To make the technical means, inventive features, objectives and effects of the invention easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to specific illustrations. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them.

[0048] Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] It should be noted that the structures, proportions, sizes, etc., illustrated in the accompanying drawings of this specification are only used to complement the content disclosed in the specification for those skilled in the art to understand and read, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0050] Furthermore, the terms such as "upper," "lower," "left," "right," "middle," and "one" used in this specification are merely for clarity of description and are not intended to limit the scope of the invention. Any changes or adjustments to their relative relationships, without substantially altering the technical content, should also be considered within the scope of the invention.

[0051] The first embodiment of the present invention provides an accelerator management method based on real-time requirements. The purpose is to drive the discovery and configuration of accelerators, and to completely hand over the use and switching of accelerator discovery drivers to users. This allows users to easily change the way they use accelerators in the cloud environment at any time, so as to meet their own business needs for accelerator use in a timely manner. This can effectively improve the user experience of accelerators in the cloud environment, while reducing operation and maintenance costs.

[0052] Definitions:

[0053] Uuid: Abbreviation for Universally Unique Identifier, which is calculated and generated based on data such as current time, counter, and hardware identifier (usually the MAC address of the wireless network card) to ensure the uniqueness of accelerator objects;

[0054] Iscover is a discovery accelerator;

[0055] The check_config_work function is used to check whether the accelerator is being used correctly.

[0056] `update_config` is used to modify how the accelerator is used.

[0057] support_accelerators are the discoverable accelerators and how they are used;

[0058] like Figure 1 As shown, in the first aspect, an accelerator management method based on real-time demand includes the following steps:

[0059] Step 1: Obtain various accelerator discovery drivers and register them in database 600;

[0060] Step 2: Obtain user requirements and construct accelerator usage requirements based on user requirements and the accelerators and usage methods that can be discovered by the accelerator discovery driver. Store these requirements in database 600. Each accelerator usage requirement in database 600 is created and modified in real time by the user based on their current business, hence it is called a real-time requirement. By comparison and judgment, ensure that there is only one usage method for the same type of accelerator on the same server 300.

[0061] Step 3: The agent service on each server 300 periodically queries the database 600 for accelerator usage requirements created based on user needs through polling. It then iterates through all accelerator usage requirements, matches a suitable accelerator discovery driver for each requirement, calls the accelerator discovery driver to complete the discovery of the accelerator and the configuration of its usage method, and generates a new accelerator object to be uploaded to the management platform 500. The shorter the polling interval, the higher the real-time performance, but the more resources are consumed. Considering all factors, it is set to 5 minutes.

[0062] Step 4: After receiving the new accelerator object, the management platform 500 queries all existing accelerator objects in the current database 600. By comparing the new accelerator object with the UUID of the existing accelerator objects, it deletes accelerator objects that exist in database 600 but are not present in the current upload, adds accelerator objects that are not present in database 600 but are present in the current upload, and updates database 600. Finally, all accelerator objects in database 600 are available for users to use.

[0063] The pseudocode for the accelerator discovery driver is as follows:

[0064]

[0065] Each accelerator discovery driver must implement four sub-functions: discover, check_config_work, update_config, and support_accelerators.

[0066] The discover sub-function returns an accelerator object;

[0067] The `check_config_work` sub-function returns a consistency flag, either True or False.

[0068] The update_config sub-function does not need to return a value;

[0069] The `support_accelerators` subroutine returns a data structure that shows discoverable accelerators and how they can be used. The data structure is as follows:

[0070]

[0071] config_type set to passthrough indicates a direct passthrough;

[0072] All methods that encounter errors during execution are thrown upwards as exceptions;

[0073] The data structure for accelerator usage requirements is as follows:

[0074]

[0075]

[0076] The accelerator object data structure is as follows:

[0077]

[0078] The UUID of the PCI type accelerator is generated using UUID3, which combines vendor_id, product_id, bus_address, and hostname as a seed value to ensure the uniqueness of the accelerator.

[0079] In the aforementioned accelerator management method based on real-time requirements, step 1 also requires determining whether each accelerator discovery driver is compliant and registering compliant accelerator discovery drivers in database 600.

[0080] like Figure 2 As shown in the above-mentioned accelerator management method based on real-time requirements, the specific method for determining whether each accelerator discovery driver is compliant and registering compliant accelerator discovery drivers into database 600 is as follows:

[0081] Step 11: The management platform 500 obtains the discovery driver for each accelerator;

[0082] Step 12: The management platform 500 traverses all accelerator discovery drivers in the current environment, queries all registered accelerator discovery drivers in the database 600, compares and determines whether each accelerator discovery driver is duplicated with all registered accelerator discovery drivers in the database 600, and deletes duplicate accelerator discovery drivers.

[0083] Step 13: Determine whether the names of each accelerator discovery driver are standardized, and delete accelerator discovery drivers whose names do not conform to the standard.

[0084] Step 14: Determine whether each accelerator discovery driver can implement the four sub-functions: discover, check_config_work, update_config, and support_accelerators, and delete the accelerator discovery drivers whose names cannot be implemented.

[0085] Step 15: Save the remaining accelerator discovery drivers to database 600.

[0086] In the above-mentioned accelerator management method based on real-time demand, step 2 also needs to determine whether the user demand is compliant, construct the accelerator usage demand by combining the compliant user demand with the accelerators that can be discovered and their usage methods provided by the accelerator discovery driver, and store it in the database 600.

[0087] like Figure 3 As shown, the above-mentioned accelerator management method based on real-time demand involves determining whether user demands are compliant, constructing accelerator usage requirements by combining compliant user demands with the accelerators and usage methods discovered by the accelerator discovery driver, and storing these requirements in database 600. The specific method for this is as follows:

[0088] Step 21: The user queries all registered accelerator discovery drivers in database 600 and obtains information on discoverable accelerators and usage methods supported by all accelerator discovery drivers;

[0089] Step 22: If the user cannot find a supported accelerator, create a user request and send it to the management platform 500;

[0090] Step 23: The management platform 500 receives user requests, queries existing accelerator usage requests in the database 600, determines whether the current user's accelerator usage request is duplicated with existing accelerator usage requests, and determines whether the parameter format of the current user's accelerator usage request conforms to the specifications. If duplicated and not conforming to the specifications, a creation failure is reported; otherwise, the accelerator usage request is constructed based on the user's request and the discoverable accelerators and usage methods provided by the accelerator discovery driver, and stored in the database 600.

[0091] like Figure 4As shown in the above-mentioned accelerator management method based on real-time demand, the specific process of step 3 is as follows:

[0092] Step 31: After the agent service on each server 300 is started, it periodically retrieves the accelerator usage requirements created based on user needs from the database 600.

[0093] Step 32: Iterate through all accelerator usage requirements and match a suitable accelerator discovery driver for each accelerator usage requirement;

[0094] Step 33: Determine whether the accelerator usage request is compliant based on the discoverable accelerators and usage methods provided by the accelerator discovery driver. If it is not compliant, discard the accelerator usage request and upload the error information to the log.

[0095] Step 34: The accelerator discovery driver calls the discover sub-function based on the vendor_id and product_id described in the accelerator discovery request to find accelerators on the current server 300 whose vendor_id and product_id match.

[0096] Step 35: The accelerator discovery driver calls the check_config_work sub-function to determine whether the usage method config_type and config_info described in the accelerator requirements are consistent with the currently discovered accelerator. If they are inconsistent, proceed to step 36; if they are consistent, proceed to step 37.

[0097] Step 36: The accelerator discovery driver calls the update_config sub-function to reconfigure the accelerator's usage.

[0098] Step 37: The accelerator discovery driver generates accelerator objects and uploads them to the agent service. The agent service integrates all accelerator objects uploaded by the accelerator discovery driver and uploads them to the management platform 500.

[0099] like Figure 5 As shown, in a second aspect, an accelerator management system based on real-time demand includes an accelerator discovery-driven registration module 100, an accelerator usage demand management module 200, a server 300, an accelerator discovery and configuration module 400, and a management platform 500.

[0100] The accelerator discovery driver registration module 100 is used to obtain various accelerator discovery drivers and register them into the database 600;

[0101] The accelerator usage demand management module 200 is used to obtain user demands, and construct accelerator usage demands based on user demands and the discoverable accelerators and usage methods provided by the accelerator discovery driver, and store them in the database 600; it is also used for users to query, create, modify and delete accelerator usage demands in the database 600 in real time.

[0102] The agent service on server 300 periodically queries the database 600 for accelerator usage requirements created based on user needs, and iterates through all accelerator usage requirements. The accelerator discovery and configuration module 400 matches a suitable accelerator discovery driver for each accelerator usage requirement, calls the accelerator discovery driver to complete the discovery of the accelerator and the configuration of its usage method, and generates a new accelerator object to be uploaded to the management platform 500.

[0103] The management platform 500 is used to receive new accelerator objects and query all existing accelerator objects in the current database 600. By comparing the new accelerator object with the UUID of the existing accelerator objects, it deletes accelerator objects that exist in the database 600 but do not exist in the current upload, adds accelerator objects that do not exist in the database 600 but exist in the current upload, and updates the database 600.

[0104] Thirdly, a chip comprising: a processor for retrieving and running a computer program from a memory, causing a device having the chip mounted to perform: the method of any of the first aspects.

[0105] For example, memory can include random access memory, flash memory, read-only memory, programmable read-only memory, non-volatile memory, or registers, etc.

[0106] The processor can be a central processing unit (CPU) or a graphics processing unit (GPU). The memory can store executable instructions.

[0107] The processor can execute instructions stored in memory to implement the various processes described in this paper.

[0108] It is understood that the memory in this embodiment can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0109] The non-volatile memory can be ROM (Read-Only Memory), PROM (Programmable ROM), EPROM (Erasable PROM), EEPROM (Electrically Erasable EPROM), or flash memory.

[0110] Volatile memory can be RAM (Random Access Memory), which is used as an external cache;

[0111] By way of example, but not limitation, many forms of RAM are available, such as SRAM (Static RAM), DRAM (Dynamic RAM), SDRAM (Synchronous DRAM), DDR SDRAM (Double Data Rate SDRAM), ESDRAM (Enhanced SDRAM), SLDRAM (Synchlink DRAM), and DRRAM (Direct Rambus RAM). The memories described herein are intended to include, but are not limited to, these and any other suitable types of memory.

[0112] In some implementations, the memory stores elements such as upgrade packages, executable units, or data structures, or subsets thereof, or extended sets thereof: operating systems and applications;

[0113] The operating system, which includes various system programs such as the framework layer, core library layer, and driver layer, is used to implement various basic business functions and handle hardware-based tasks.

[0114] Applications, encompassing various applications, are used to implement various application services. Programs implementing the methods of embodiments of the present invention can be included within these applications.

[0115] Those skilled in the art will understand that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of software and electronic hardware.

[0116] Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution.

[0117] Those skilled in the art can implement the described functions in different ways for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0118] In the embodiments of this application, the disclosed systems, apparatus and methods can be implemented in other ways;

[0119] For example, the division of units or modules is only a logical functional division, and there may be other division methods in actual implementation;

[0120] For example, multiple units, modules, or components can be combined or integrated into another system;

[0121] In addition, each functional unit or module in the embodiments of this application can be integrated into a processing unit or module, or it can exist as a separate physical entity, etc.

[0122] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0123] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a machine-readable storage medium.

[0124] Therefore, the technical solution of this application can be embodied in the form of a software product, which can be stored in a machine-readable storage medium and can contain several instructions to cause an electronic device to execute all or part of the process of the technical solution described in the embodiments of this application.

[0125] The aforementioned storage media can include various media capable of storing program code, such as ROM, RAM, removable disk, hard disk, magnetic disk, or optical disk.

[0126] In summary, the accelerator management method and system based on real-time requirements of the present invention can drive management by discovering and configuring accelerators, and completely hand over the use and switching of accelerator discovery drivers to users. This allows users to easily change the way they use accelerators in the cloud environment at any time, so as to meet their own business needs for accelerator use in a timely manner. This can effectively improve the user experience of accelerators in the cloud environment, while reducing operation and maintenance costs.

[0127] The specific embodiments of the invention have been described above. It should be understood that the invention is not limited to the specific embodiments described above, and the devices and structures not described in detail should be understood to be implemented in a manner common to the art; those skilled in the art can make various modifications or alterations within the scope of the claims, and make several simple deductions, variations or substitutions, which do not affect the substantive content of the invention.

Claims

1. An accelerator management method based on real-time demand, characterized in that, Includes the following steps: Step 1: Obtain various accelerator discovery drivers, determine whether each accelerator discovery driver is compliant, and register the compliant accelerator discovery drivers to the database. The specific method is as follows: The management platform obtains the accelerator discovery drivers mentioned above; The management platform iterates through all accelerator discovery drivers in the current environment, queries all registered accelerator discovery drivers in the database, compares and determines whether each accelerator discovery driver is duplicated with all registered accelerator discovery drivers in the database, and deletes duplicate accelerator discovery drivers. Determine if the names of each accelerator discovery driver are standardized, and delete accelerator discovery drivers whose names do not conform to the standard. Determine whether each accelerator discovery driver can implement the four sub-functions: discover, check_config_work, update_config, and support_accelerators. Delete accelerator discovery drivers that cannot implement these functions. Here, discover is for discovering accelerators, check_config_work is for verifying whether the accelerator usage is consistent, update_config is for modifying the accelerator usage, and support_accelerators is for discoverable accelerators and their usage. Save the remaining accelerator discovery drivers to the database; Step 2: Obtain user needs, and construct accelerator usage requirements based on user needs and the accelerators and usage methods that the accelerator discovery driver can discover, and store them in the database. Each accelerator usage requirement in the database is created and modified in real time by the user according to their current business. Step 3: The agent service on each server periodically queries the database for the accelerator usage requirements created based on user needs, iterates through all accelerator usage requirements, matches a suitable accelerator discovery driver for each accelerator usage requirement, calls the accelerator discovery driver to complete the discovery of the accelerator and the configuration of the usage method, and generates a new accelerator object to be uploaded to the management platform. The specific process of step 3 is as follows: Step 31: After the agent service on each server starts, it periodically retrieves the accelerator usage requirements created based on user needs from the database; Step 32: Iterate through all accelerator usage requirements and match a suitable accelerator discovery driver for each accelerator usage requirement; Step 33: Determine whether the accelerator usage request is compliant based on the discoverable accelerators and usage methods provided by the accelerator discovery driver. If it is not compliant, discard the accelerator usage request and upload the error information to the log. Step 34: The accelerator discovery driver calls the discover sub-function based on the vendor_id and product_id described in the accelerator discovery requirement to find accelerators on the current server whose vendor_id and product_id match. Step 35: The accelerator discovery driver calls the check_config_work sub-function to determine whether the usage method config_type and config_info described in the accelerator requirements are consistent with the currently discovered accelerator. If they are inconsistent, proceed to step 36; if they are consistent, proceed to step 37. Step 36: The accelerator discovery driver calls the update_config sub-function to reconfigure the accelerator's usage, and then proceeds to step 37; Step 37: The accelerator discovery driver generates accelerator objects and uploads them to the agent service. The agent service integrates all accelerator objects uploaded by the accelerator discovery driver and uploads them to the management platform. Step 4: After receiving the new accelerator object, the management platform queries all existing accelerator objects in the current database, compares the new accelerator object with the UUID of the existing accelerator objects, deletes accelerator objects that exist in the database but are not present in the current upload, adds accelerator objects that do not exist in the database but are present in the current upload, and updates the database.

2. The accelerator management method based on real-time demand as described in claim 1, characterized in that, Step 2 also requires determining whether the user's requirements are compliant. The compliant user requirements are then combined with the accelerators that the accelerator discovery driver can discover and their usage methods to construct the accelerator usage requirements, which are then stored in the database.

3. The accelerator management method based on real-time demand as described in claim 2, characterized in that, The specific method for determining whether the user requirements are compliant, constructing the accelerator usage requirements by combining the compliant user requirements with the accelerators that the accelerator discovery driver can discover and their usage methods, and storing them in the database is as follows: Step 21: The user queries the database for all registered accelerator discovery drivers and obtains information on discoverable accelerators and usage methods supported by all accelerator discovery drivers; Step 22: If the user cannot find a supported accelerator, create a user request and send it to the management platform; Step 23: The management platform receives the user's request, queries the database for existing accelerator usage requests, determines whether the current user's accelerator usage request is duplicated with an existing accelerator usage request, and determines whether the parameter format of the current user's accelerator usage request conforms to the specifications. If it is duplicated and does not conform to the specifications, a creation failure is reported; otherwise, the accelerator usage request is constructed based on the user's request and the accelerators and users that the accelerator discovery driver can discover, and stored in the database.

4. An accelerator management system based on real-time demand, used to implement the method according to any one of claims 1 to 3, characterized in that, Includes an accelerator discovery driver registration module, an accelerator usage requirement management module, a server, an accelerator discovery and configuration module, and a management platform. The accelerator discovery driver registration module is used to acquire various accelerator discovery drivers and register them in the database. The accelerator uses a demand management module to obtain user demands and, based on these demands, the accelerator discovers... The driver provides information on discoverable accelerators and their usage methods to build accelerator usage requirements and stores them in the database. It is also used for users to query, create, modify, and delete accelerator usage requirements in the database in real time; The agent service on the server periodically queries the database for the accelerator usage requirements created based on user needs, and iterates through all accelerator usage requirements. The accelerator discovery and configuration module matches a suitable accelerator discovery driver for each accelerator usage requirement, calls the accelerator discovery driver to complete the discovery of the accelerator and the configuration of its usage method, and generates a new accelerator object to be uploaded to the management platform. The management platform is used to receive the new accelerator object and query all existing accelerators in the current database. Accelerator objects are compared with the UUID of the new accelerator object, and then deleted from the database if they already exist. However, if an accelerator object does not exist in the current upload, add an accelerator object that does not exist in the database but exists in the current upload. The device object is updated, and the database is updated.

5. A chip, characterized in that, It includes: a processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform: the method as described in any one of claims 1 to 3.

Images