Accelerator card equipment configuration method and device, equipment and storage medium

Abstract

The invention discloses an accelerator card equipment configuration method and device, equipment and a storage medium, relates to the field of computers, is applied to a server side, and comprises the following steps: acquiring a target configuration creation request corresponding to target accelerator card equipment sent by a user side by utilizing a target application programming interface, and performing target parameter verification on the target configuration creation request; if the target parameter verification is passed, determining a corresponding target driving component by using the target agent, and storing target configuration data corresponding to the target driving component to a target database by using the target service; acquiring target configuration data from a target database by using the target agent to determine a target device list, determining a target driving component based on the target device list, and initializing a target accelerator card device in the target device list by using the target driving component, and storing the device information corresponding to the target accelerator card device to the target database by using the target service. According to the invention, the management complexity of the acceleration card equipment is reduced.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to an accelerator card device configuration method, apparatus, device and storage medium. Background Art

[0002] Currently, to increase computing density, the number of accelerator cards on a single computing node is generally greater than or equal to 8. Due to differences in motherboards and other factors, the PCI (Peripheral Component Interconnect) slots of accelerator card devices on different computing nodes also vary. In a whitelist-based configuration, a different PCI address whitelist must be configured for each computing node. The large number of configured nodes and devices results in a large configuration workload and is prone to errors, leading to rework.

[0003] In summary, how to reduce the complexity of accelerator card device management is an urgent problem to be solved. Summary of the Invention

[0004] In view of this, the present invention aims to provide an accelerator card device configuration method, apparatus, device, and storage medium that can reduce the complexity of accelerator card device management. The specific solution is as follows:

[0005] In a first aspect, the present application discloses a method for configuring an accelerator card device, which is applied to a server and includes:

[0006] Utilizing a target application programming interface to obtain a target configuration creation request corresponding to a target accelerator card device sent by a user terminal, and performing target parameter verification on the target configuration creation request based on a pre-configured target data table; the target data table is a data table configured in a target component of OpenStack heterogeneous device management; the target parameter verification includes request permission verification and configuration information verification;

[0007] If the target configuration creation request passes the target parameter verification, using the target agent to determine the target driver component corresponding to the target accelerator card device based on the target configuration creation request, and using the target service to save the target configuration data corresponding to the target driver component to the target database;

[0008] The target agent is used to obtain the target configuration data from the target database, the target configuration data is parsed to determine a target device list, the target driver component is determined based on the target device list, and the target driver component is used to initialize the target accelerator card device in the target device list, and the target service is used to save the device information corresponding to the target accelerator card device to the target database.

[0009] Optionally, the target data table includes a node registration device ID, a device descriptor, a computing node ID, and a configuration status; the computing node ID is associated with a computing node corresponding to the computing node ID through a foreign key.

[0010] Optionally, performing target parameter verification on the target configuration creation request based on a pre-configured target data table includes:

[0011] Performing a request permission check on the target configuration creation request;

[0012] If the target configuration creation request fails to pass the request authority verification, terminating the target configuration creation operation and returning the corresponding first request result to the user terminal;

[0013] If the target configuration creation request passes the request authority check, performing configuration information verification on the target configuration creation request based on a pre-configured target data table;

[0014] The step of verifying the configuration information of the target configuration creation request includes:

[0015] Verify whether the computing node corresponding to the computing node field in the target configuration creation request is legal and exists;

[0016] Verify whether the computing nodes corresponding to the computing node fields are different;

[0017] Verify whether the description field in the target configuration creation request conforms to a preset configuration format and whether at least one item is not empty.

[0018] Optionally, if the target configuration creation request passes the target parameter verification, determining a target driver component corresponding to the target accelerator card device based on the target configuration creation request by using a target agent includes:

[0019] If the target configuration creation request passes the target parameter verification, sending the target configuration creation request to the target service using the target application programming interface;

[0020] Determine, by using the target service and based on the computing node field in the target configuration creation request, a target proxy corresponding to the target configuration creation request;

[0021] The target agent is used to determine a target driver component corresponding to the target accelerator card device based on the target configuration creation request.

[0022] Optionally, the determining, by the target agent based on the target configuration creation request, a target driver component corresponding to the target accelerator card device includes:

[0023] Using the target agent to read the devices to be configured under the target path to determine a list of devices to be configured;

[0024] Determine a target PCI address list based on the list of devices to be configured and the target configuration creation request; the target PCI address list includes a target PCI address corresponding to the target accelerator card device;

[0025] Using the target agent to load all driver components in the driver directory;

[0026] The driver components and the devices to be configured are matched based on the target PCI address list to determine target driver components corresponding to the target accelerator card devices.

[0027] Optionally, matching the driver components and the devices to be configured based on the target PCI address list to determine a target driver component corresponding to each target accelerator card device includes:

[0028] If the target accelerator card device corresponding to the target PCI address in the target PCI address list does not match any of the driver components, terminating the target configuration creation operation for the target accelerator card, and returning a corresponding second request result to the user terminal using the target application programming interface;

[0029] The second request result includes a configuration creation failure reason and a configuration creation process record corresponding to the target configuration creation request.

[0030] Optionally, the accelerator card device configuration method further includes:

[0031] Configuring a device quantity dictionary for each target agent;

[0032] Determining, using the target agent based on the device quantity dictionary, whether the target accelerator card device has multiple chips;

[0033] If the target accelerator card device has multiple chips, a PCIe switch corresponding to the target accelerator card device is determined, and a PCI address corresponding to the PCIe switch is determined as the target PCI address corresponding to the target accelerator card.

[0034] In a second aspect, the present application discloses an accelerator card device configuration device, which is applied to a server, comprising:

[0035] A parameter verification module is configured to utilize a target application programming interface to obtain a target configuration creation request corresponding to a target accelerator card device sent by a user terminal, and to perform target parameter verification on the target configuration creation request based on a pre-configured target data table; the target data table is a data table configured in a target component of OpenStack heterogeneous device management; the target parameter verification includes request permission verification and configuration information verification;

[0036] a driver configuration data saving module, configured to, if the target configuration creation request passes the target parameter verification, use a target agent to determine a target driver component corresponding to the target accelerator card device based on the target configuration creation request, and use a target service to save the target configuration data corresponding to the target driver component to a target database;

[0037] A device information saving module is used to use the target agent to obtain the target configuration data from the target database, parse the target configuration data to determine a target device list, determine the target driver component based on the target device list, initialize the target accelerator card device in the target device list using the target driver component, and use the target service to save the device information corresponding to the target accelerator card device to the target database.

[0038] In a third aspect, the present application discloses an electronic device, comprising:

[0039] Memory, used to store computer programs;

[0040] The processor is configured to execute the computer program to implement the aforementioned accelerator card device configuration method.

[0041] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program, wherein the computer program implements the aforementioned accelerator card device configuration method when executed by a processor.

[0042] In this application, when configuring an accelerator card device, the server uses a target application programming interface to obtain a target configuration creation request corresponding to a target accelerator card device sent by a user end, and performs target parameter verification on the target configuration creation request based on a pre-configured target data table; the target data table is a data table configured in a target component managed by OpenStack heterogeneous devices; the target parameter verification includes request permission verification and configuration information verification; if the target configuration creation request passes the target parameter verification, the target agent is used to determine the target driver component corresponding to the target accelerator card device based on the target configuration creation request, and the target service is used to save the target configuration data corresponding to the target driver component to the target database; the target agent is used to obtain the target configuration data from the target database, and the target configuration data is parsed to determine a target device list, so as to determine the target driver component based on the target device list, and the target driver component is used to initialize the target accelerator card device in the target device list, and the target service is used to save the device information corresponding to the target accelerator card device to the target database. It can be seen that when configuring each accelerator card device, the server can perform target parameter verification on the target configuration creation request based on the target data table when obtaining the target configuration creation request sent by the user segment through the application programming interface, so as to determine whether the configuration creation can be performed for the target accelerator card device. If the configuration creation can be performed for the target accelerator card device, the target driver component corresponding to the target accelerator card device will be determined first, and then the target configuration data corresponding to the target driver component will be saved to the target database to complete the configuration insertion. After that, the target agent will obtain these target configuration information from the target database, and determine the target device list and target driver component corresponding to the target agent containing all target accelerator card devices by parsing the configuration information, so as to perform initialization operations on all target accelerator card devices using the target driver component, and finally save the device information of these target accelerator card devices to the target database, thereby realizing the management of accelerator card device identification and upload through the RESTful API. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0044] Figure 1 This is a flow chart of a method for configuring an accelerator card device disclosed in this application;

[0045] Figure 2A schematic diagram of a server architecture disclosed in this application;

[0046] Figure 3 This is a flowchart of a specific accelerator card device configuration method disclosed in this application;

[0047] Figure 4 This is a schematic diagram of the structure of an accelerator card device configuration device disclosed in this application;

[0048] Figure 5 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0049] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0050] Currently, to increase computing density, the number of accelerator cards on a single computing node is generally greater than or equal to eight. Due to differences in motherboards and other factors, the PCI slots of accelerator card devices on different computing nodes also vary. In a whitelist-based configuration, a different PCI address whitelist must be configured for each computing node. This large number of nodes and devices results in a large configuration workload and is prone to errors, leading to rework. To address the above technical issues, this application discloses a method for configuring accelerator card devices that reduces the complexity of accelerator card device management.

[0051] See also Figure 1 As shown, an embodiment of the present invention discloses an accelerator card device configuration method, which is applied to a server, including:

[0052] Step S11: Utilize the target application programming interface to obtain a target configuration creation request corresponding to the target accelerator card device sent by the user terminal, and perform target parameter verification on the target configuration creation request based on a pre-configured target data table; the target data table is a data table configured in the target component of OpenStack heterogeneous device management; the target parameter verification includes request permission verification and configuration information verification.

[0053] In this embodiment, Figure 2This is a diagram of the server architecture. In addition to using the target application programming interface to obtain target configuration creation requests for target accelerator devices sent by the client, the server also supports managing a passthrough device list through configuration files. This includes configuring PCI addresses as a whitelist for accelerator devices, configuring the vendor and device IDs of PCI devices in the management service, and configuring a blacklist based on PCI addresses. The whitelist format is a dotted PCI device address in the format of DDDD:BB:SS.FF, where D identifies the PCI device domain, B identifies the bus address, S identifies the slot, and F identifies the function number. This enumerates all device addresses that need to be passthrough to the VM. The vendor ID identifies the device manufacturer, and the device ID identifies the device model. The vendor ID uniquely identifies the device manufacturer. The PCI address blacklist format is the same as the whitelist format to exclude devices not managed by OpenStack.

[0054] When the server creates and manages the device list on each compute node through the target API (Application Programming Interface), it can perform various target parameter checks on the target configuration creation request based on the target data table created in the relevant components of OpenStack heterogeneous device management (such as Nova and Cyborg). As shown in Table 1 below, the target data table includes the node registration device ID, device descriptor, compute node ID, and configuration status; the compute node ID is associated with the compute node corresponding to the compute node ID through a foreign key. The device descriptor field is in TEXT format, the configuration status field type is an integer, and describes whether the device described by the device descriptor is enabled; whether it is whitelisted indicates whether the field identified by the device descriptor is available.

[0055] Table 1

[0056]

[0057] In this embodiment, the RESTful API interface (also known as the target application programming interface) implemented in the API layer is responsible for receiving the target configuration creation request sent by the user. The target configuration creation request can be input in JSON format and supports matching multiple compute nodes. The compute_node field can be the UUID of the compute node service or other string that can uniquely identify the compute node service. The descriptor describes the type of device managed by the compute node. The vendor, device, whitelist, and blacklist fields can be empty, but cannot be empty at the same time. The target configuration creation request can specifically be:

[0058] {

[0059] "nodes": [

[0060] {

[0061] "compute_node": "xxxxx",

[0062] "descriptor": {

[0063] "vendor": "123",

[0064] “device”: “123”,

[0065] "whitelist": [

[0066] ],

[0067] "blacklist": [ ]

[0069] },

[0070] "enabled": true

[0071] } ]

[0073] }.

[0074] In this embodiment, Figure 3As shown, after obtaining the target configuration creation request through the target API, the server performs target parameter verification on the target configuration creation request based on the pre-configured target data table. The target parameter verification includes request permission verification and configuration information verification. The verification process can specifically include: performing request permission verification on the target configuration creation request; if the target configuration creation request fails to pass the request permission verification, terminating the target configuration creation operation, and returning the corresponding first request result to the user end; if the target configuration creation request passes the request permission verification, performing configuration information verification on the target configuration creation request based on the pre-configured target data table. In a specific embodiment, performing configuration information verification on the target configuration creation request includes: verifying whether the computing node corresponding to the computing node field in the target configuration creation request is legal and exists; verifying whether the computing nodes corresponding to the computing node field are different; verifying whether the description field in the target configuration creation request conforms to the preset configuration format and at least one item is not empty.

[0075] In a specific embodiment, after receiving the configuration creation request, the API service first performs necessary parameter verification, and needs to verify the operation authority of the user who calls the API (i.e., permission verification), reject the operation of the user who does not meet the calling authority, and return 403. Then, the configuration information verification is performed, which may specifically include: verifying that the compute_node is legal and exists. If the node does not exist, the request to create the configuration is rejected and 404 is returned; verifying that all items in the descriptor field are not all empty. If they do not meet the requirements, 406 is returned; checking that the compute_node in the node list in the request is not repeated, and rejecting requests for multiple identical compute_nodes in multiple requests and returning 406; verifying the configuration in the whitelist and blacklist of the descriptor under the compute_node of each request. The configuration format is required to meet the standard PCI address format. If it does not meet the requirements, the user request is rejected and 406 is returned.

[0076] In this embodiment, since some accelerator card devices integrate multiple accelerator card device chips onto a single PCIe switch and then package them, when these accelerator card devices are inserted into a compute node server, the server's operating system will see two or more accelerator chips, with the parent device of these accelerator chips being the PCIe switch. To identify these accelerator card devices with multiple chips, this embodiment configures a device quantity dictionary for each target agent. The target agent then uses the corresponding device quantity dictionary to determine whether the target accelerator card device has multiple chips. If the target accelerator card device has multiple chips, the target agent determines the PCIe switch corresponding to the target accelerator card device and uses the PCI address corresponding to the PCIe switch as the target PCI address corresponding to the target accelerator card. Specifically, this embodiment implements a device quantity dictionary in the agent (i.e., target agent) code. Specifically, the accelerator card device's Vendor ID, Device ID, and Subsystem Device ID are used as keys, and a Boolean value is used as the value to identify whether the corresponding accelerator card device has multiple chips. A "multi-chip" flag is also configured for accelerator card devices with multiple chips. When the agent discovers and registers the accelerator device, if the accelerator card driver identifies the corresponding PCI device as a multi-core device, it identifies the PCIe switch where the device is located and assigns the PCI address of the PCIe switch as an attribute to the accelerator card device. In a specific embodiment, to identify the PCIe switch where the accelerator card device is located, the virtual link file of the device's PCIe BDF under / sys / bu / pci / devices is first located. The actual path of the device is identified through readlink, and the path of the device's parent directory is read through dirname. The PCI address of the parent directory is obtained through dirname. This address is the shared PCIe switch of the multi-core device.

[0077] Step S12: If the target configuration creation request passes the target parameter verification, the target agent is used to determine the target driver component corresponding to the target accelerator card device based on the target configuration creation request, and the target configuration data corresponding to the target driver component is saved to the target database using the target service.

[0078] In this embodiment, if the target configuration creation request passes the target parameter verification, the target driver component corresponding to the target accelerator card device is determined based on the target configuration creation request using the target agent, including: if the target configuration creation request passes the target parameter verification, the target application programming interface is used to send the target configuration creation request to the target service; the target service is used to determine the target agent corresponding to the target configuration creation request based on the computing node field in the target configuration creation request; and the target driver component corresponding to the target accelerator card device is determined based on the target configuration creation request using the target agent. The process of determining the target driver component corresponding to the target accelerator card device based on the target configuration creation request using the target agent can specifically include: using the target agent to read the devices to be configured under the target path to determine the list of devices to be configured; determining the target PCI address list based on the list of devices to be configured and the target configuration creation request; the target PCI address list includes the target PCI address corresponding to the target accelerator card device; using the target agent to load all driver components under the driver directory; matching the driver components and the devices to be configured based on the target PCI address list to determine the target driver component corresponding to each target accelerator card device. After determining the target driver component, the target service will save the target configuration data corresponding to the target driver component into the target database. In addition, if the target accelerator card device corresponding to the target PCI address in the target PCI address list does not match any driver component, the target configuration creation operation for the target accelerator card is terminated, and the corresponding second request result is returned to the user end using the target application programming interface; wherein the second request result includes the configuration creation failure reason and the configuration creation process record corresponding to the target configuration creation request.

[0079] In a specific implementation, after checking that the configuration meets the requirements, the API service sends the request to the Conductor service (also known as the target service), which is further checked and persisted by the Conductor service. The Conductor service first searches for the Agent service corresponding to the node through the compute_node field of the configuration, and sends the configuration to the Agent service for verification. After receiving the request, the Agent service can read the device list under / sys / bus / pci / devices, assemble its PCI address, Vendor ID, Device ID, etc., and compare it with the incoming descriptor to filter out the PCI address list that meets the requirements. If the list is empty, the request is rejected and a customizable exception code is returned to the Conductor service. If the PCI address is not empty, the Agent service loads all driver devices in the driver directory and scans the devices in the PCI address. If the PCI device has a supported driver, it matches and checks the next device. If the PCI device does not have a supported driver, it exits and returns an exception code and PCI address information, indicating that this PCI device does not support management. If the Conductor receives an exception code returned by the Agent, it notifies the API of the exception, and the API responds to the user and records the error cause and error details that the user can understand. If the Agent checks and there are no problems, the Conductor will configure the storage record, and the API will return 200 to the user, prompting that the configuration insertion is complete. In this way, in response to the situation where there are many acceleration devices on the computing node and the PCI addresses of the acceleration cards on each computing node are different, this embodiment implements a method for configuring the available acceleration devices on the computing node through the API. While ensuring the flexible configuration of the computing card, it reduces the complexity of the configuration and can achieve online configuration without restarting the service.

[0080] Step S13: Using the target agent to obtain the target configuration data from the target database, parsing the target configuration data to determine a target device list, determining the target driver component based on the target device list, and using the target driver component to initialize the target accelerator card device in the target device list, and using the target service to save the device information corresponding to the target accelerator card device to the target database.

[0081] In this embodiment, after configuration insertion is complete, the target agent reads the target configuration data saved in the previous steps from the target database and parses this data to determine the target device list. Based on the target device list, the target driver component corresponding to the target accelerator card device is then loaded and initialized using the target driver component. After initialization is complete, the target agent notifies the Conductor via an RPC (Remote Procedure Call) and stores the accelerator device information. This enables the identification and upload of accelerator card devices to be managed via a RESTful API.

[0082] In a specific embodiment, when the Agent driver initializes the device, in / sys / bus / pci / devices / <PCI ID> The device ID and subsystem device ID are read from the folder, and two default attributes are set for the acceleration device to identify the device model. In order to solve the problem of repeated Device IDs in domestic accelerator cards, a method for reading the subsystem device ID of the device is provided, and the subsystem device ID is associated with the accelerator card device as an attribute, realizing the flexible distinction between different models of accelerator cards with the same Device ID. The file corresponding to DeviceID is: / sys / bus / pci / devices / <PCI ID> / device; The file corresponding to the Subsystem Device ID is / sys / bus / pci / devices / <PCI ID> / subsystem_device.

[0083] In OpenStack, the accelerator card device is used as a resource provider. Cyborg-Agent configures the device and subsystem device-related traits for the resource provider through the interface provided by the placement service. An optional attribute name mode is: CUSTOM_TRAIT_<VENDOR_NAME> _<DEVICE_ID> and CUSTOM_TRAIT_<VENDOR_NAME> _<DEVICE_ID> _<SUBDEVICE_ID> During deployment, you can configure the relevant traits in the virtual machine's specifications to automatically schedule it to a specific GPU model. When the user chooses to mount a physical card, they can configure same_card=true in the virtual machine's device profile. When creating a virtual machine, Nova-Conductor requests an accelerator device creation request (ARQ) from Cyborg-API. The ARQ request contains the unique identifier of the accelerator device being requested (such as the PCI address) and same_card=True. Cyborg-API forwards the heterogeneous computing device creation request to the Cyborg-Conductor service. When the Cyborg-Conductor service receives the request and checks that the same_card attribute in the request is True, it first queries the database for the accelerator card's object information based on the PCI number. It then uses the multi-core identifier to confirm that the device is a multi-core card. If so, it obtains the device's PCIe switch attributes and uses the PCIe switch's unique identifier to query a list of accelerator devices with the same attributes on the compute node. These accelerator cards that meet the requirements are then bound to the virtual machine information. When Nova-Compute creates a virtual machine, it queries the Cyborg-API to obtain information about the accelerator devices associated with the virtual machine and assembles all related accelerator cards into a virtual machine configuration that meets the requirements. This achieves the goal of mounting the cores on all accelerator devices and supports transparently transmitting multiple cores on an accelerator card to the same virtual machine for use, ensuring efficient communication between accelerator cards.

[0084] It can be seen that when configuring each accelerator card device, the server can perform target parameter verification on the target configuration creation request based on the target data table when obtaining the target configuration creation request sent by the user segment through the application programming interface, so as to determine whether the configuration creation can be performed for the target accelerator card device. If the configuration creation can be performed for the target accelerator card device, the target driver component corresponding to the target accelerator card device will be determined first, and then the target configuration data corresponding to the target driver component will be saved to the target database to complete the configuration insertion. After that, the target agent will obtain these target configuration information from the target database, and determine the target device list and target driver component corresponding to the target agent containing all target accelerator card devices by parsing the configuration information, so as to perform initialization operations on all target accelerator card devices using the target driver component, and finally save the device information of these target accelerator card devices to the target database, thereby realizing the management of accelerator card device identification and upload through RESTful API.

[0085] See also Figure 4 As shown, the present application discloses an accelerator card device configuration device, which is applied to the server, including:

[0086] A parameter verification module 11 is configured to obtain a target configuration creation request corresponding to a target accelerator card device sent by a user terminal using a target application programming interface, and perform target parameter verification on the target configuration creation request based on a pre-configured target data table; the target data table is a data table configured in a target component of OpenStack heterogeneous device management; the target parameter verification includes request permission verification and configuration information verification;

[0087] a driver configuration data saving module 12 configured to, if the target configuration creation request passes the target parameter verification, determine the target driver component corresponding to the target accelerator card device based on the target configuration creation request using a target agent, and save the target configuration data corresponding to the target driver component to a target database using a target service;

[0088] The device information saving module 13 is used to use the target agent to obtain the target configuration data from the target database, parse the target configuration data to determine a target device list, determine the target driver component based on the target device list, initialize the target accelerator card device in the target device list using the target driver component, and use the target service to save the device information corresponding to the target accelerator card device to the target database.

[0089] It can be seen that when configuring each accelerator card device, the server can perform target parameter verification on the target configuration creation request based on the target data table when obtaining the target configuration creation request sent by the user segment through the application programming interface, so as to determine whether the configuration creation can be performed for the target accelerator card device. If the configuration creation can be performed for the target accelerator card device, the target driver component corresponding to the target accelerator card device will be determined first, and then the target configuration data corresponding to the target driver component will be saved to the target database to complete the configuration insertion. After that, the target agent will obtain these target configuration information from the target database, and determine the target device list and target driver component corresponding to the target agent containing all target accelerator card devices by parsing the configuration information, so as to perform initialization operations on all target accelerator card devices using the target driver component, and finally save the device information of these target accelerator card devices to the target database, thereby realizing the management of accelerator card device identification and upload through RESTful API.

[0090] In a specific implementation, the parameter verification module 11 may specifically include:

[0091] The permission verification submodule is used to perform a request permission verification on the target configuration creation request;

[0092] a first request result returning submodule, configured to terminate the target configuration creation operation and return the corresponding first request result to the user terminal if the target configuration creation request fails to pass the request authority verification;

[0093] a configuration information verification submodule, configured to perform configuration information verification on the target configuration creation request based on a pre-configured target data table if the target configuration creation request passes the request authority verification;

[0094] The configuration information check submodule may specifically include:

[0095] A first verification unit, configured to verify whether the computing node corresponding to the computing node field in the target configuration creation request is legal and exists;

[0096] A second verification unit, configured to verify whether the computing nodes corresponding to the computing node field are different;

[0097] The third verification unit is used to verify whether the description field in the target configuration creation request complies with a preset configuration format and whether at least one item is not empty.

[0098] In a specific implementation, the driver configuration data storage module 12 may specifically include:

[0099] a request forwarding submodule, configured to send the target configuration creation request to a target service using the target application programming interface if the target configuration creation request passes the target parameter verification;

[0100] An agent determination submodule, configured to determine a target agent corresponding to the target configuration creation request based on a computing node field in the target configuration creation request using the target service;

[0101] The driver component determination submodule is configured to use the target agent to determine a target driver component corresponding to the target accelerator card device based on the target configuration creation request.

[0102] In a specific implementation, the driving component determines the submodule, which may specifically include:

[0103] a device list determining unit, configured to use the target agent to read the devices to be configured under the target path to determine a list of devices to be configured;

[0104] An address list determining unit, configured to determine a target PCI address list based on the list of devices to be configured and the target configuration creation request; the target PCI address list includes a target PCI address corresponding to the target accelerator card device;

[0105] A driver component loading unit, configured to load all driver components in the driver directory using the target agent;

[0106] The driver component determination unit is configured to match the driver components with the devices to be configured based on the target PCI address list to determine a target driver component corresponding to each target accelerator card device.

[0107] In a specific implementation, the drive component determination unit may be specifically configured to:

[0108] If the target accelerator card device corresponding to the target PCI address in the target PCI address list does not match any of the driver components, terminating the target configuration creation operation for the target accelerator card, and returning a corresponding second request result to the user terminal using the target application programming interface;

[0109] The second request result includes a configuration creation failure reason and a configuration creation process record corresponding to the target configuration creation request.

[0110] In a specific embodiment, the device may further include:

[0111] A device quantity dictionary configuration module, configured to configure a device quantity dictionary for each target agent;

[0112] a chip quantity determination unit, configured to determine, using the target agent and based on the device quantity dictionary, whether the target accelerator card device has multiple chips;

[0113] The address determination module is used to determine the PCIe switch corresponding to the target accelerator card device if the target accelerator card device has multiple chips, and determine the PCI address corresponding to the PCIe switch as the target PCI address corresponding to the target accelerator card.

[0114] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram should not be considered as any limitation to the scope of application of the present application.

[0115] Figure 5 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the accelerator card device configuration method disclosed in any of the aforementioned embodiments. Furthermore, the electronic device 20 in this embodiment may be a computer.

[0116] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0117] In addition, the memory 22 as a carrier for resource storage can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0118] The operating system 221 is used to manage and control the hardware devices on the electronic device 20 and the computer program 222. The operating system 221 can be Windows Server, NetWare, Unix, Linux, etc. In addition to including a computer program capable of implementing the accelerator card device configuration method executed by the electronic device 20 as disclosed in any of the aforementioned embodiments, the computer program 222 can further include computer programs capable of completing other specific tasks.

[0119] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when executed by a processor, the computer program implements the aforementioned accelerator card device configuration method. The specific steps of this method can be referred to the corresponding content disclosed in the aforementioned embodiments and will not be repeated here.

[0120] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0121] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may 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.

[0122] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0123] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0124] The above is a detailed introduction to the technical solution provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the ideas of the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for configuring an accelerator card device, characterized in that: Applied to the server, including: Utilizing a target application programming interface to obtain a target configuration creation request corresponding to a target accelerator card device sent by a user terminal, and performing target parameter verification on the target configuration creation request based on a pre-configured target data table; the target data table is a data table configured in a target component of OpenStack heterogeneous device management; the target parameter verification includes request permission verification and configuration information verification; If the target configuration creation request passes the target parameter verification, using the target agent to determine the target driver component corresponding to the target accelerator card device based on the target configuration creation request, and using the target service to save the target configuration data corresponding to the target driver component to the target database; The target agent is used to obtain the target configuration data from the target database, the target configuration data is parsed to determine a target device list, the target driver component is determined based on the target device list, and the target driver component is used to initialize the target accelerator card device in the target device list, and the target service is used to save the device information corresponding to the target accelerator card device to the target database.

2. The accelerator card device configuration method according to claim 1, characterized in that: The target data table includes a node registration device ID, a device descriptor, a computing node ID, and a configuration status; the computing node ID is associated with a computing node corresponding to the computing node ID through a foreign key.

3. The accelerator card device configuration method according to claim 1, characterized in that: The performing target parameter verification on the target configuration creation request based on the pre-configured target data table includes: Performing a request permission check on the target configuration creation request; If the target configuration creation request fails to pass the request authority verification, terminating the target configuration creation operation and returning the corresponding first request result to the user terminal; If the target configuration creation request passes the request authority check, performing configuration information verification on the target configuration creation request based on a pre-configured target data table; The step of verifying the configuration information of the target configuration creation request includes: Verify whether the computing node corresponding to the computing node field in the target configuration creation request is legal and exists; Verify whether the computing nodes corresponding to the computing node fields are different; Verify whether the description field in the target configuration creation request conforms to a preset configuration format and whether at least one item is not empty.

4. The method for configuring an accelerator card device according to claim 1, wherein: If the target configuration creation request passes the target parameter verification, determining the target driver component corresponding to the target accelerator card device based on the target configuration creation request using a target agent, including: If the target configuration creation request passes the target parameter verification, sending the target configuration creation request to the target service using the target application programming interface; Determine, by using the target service and based on the computing node field in the target configuration creation request, a target proxy corresponding to the target configuration creation request; The target agent is used to determine a target driver component corresponding to the target accelerator card device based on the target configuration creation request.

5. The method for configuring an accelerator card device according to claim 4, wherein: The determining, by the target agent based on the target configuration creation request, a target driver component corresponding to the target accelerator card device includes: Using the target agent to read the devices to be configured under the target path to determine a list of devices to be configured; Determine a target PCI address list based on the list of devices to be configured and the target configuration creation request; the target PCI address list includes a target PCI address corresponding to the target accelerator card device; Using the target agent to load all driver components in the driver directory; The driver components and the devices to be configured are matched based on the target PCI address list to determine target driver components corresponding to the target accelerator card devices.

6. The method for configuring an accelerator card device according to claim 5, wherein: The matching of the driver components and the devices to be configured based on the target PCI address list to determine target driver components corresponding to the target accelerator card devices includes: If the target accelerator card device corresponding to the target PCI address in the target PCI address list does not match any of the driver components, terminating the target configuration creation operation for the target accelerator card, and returning a corresponding second request result to the user terminal using the target application programming interface; The second request result includes a configuration creation failure reason and a configuration creation process record corresponding to the target configuration creation request.

7. The method for configuring an accelerator card device according to claim 5, wherein: Also includes: Configuring a device quantity dictionary for each target agent; Determining, using the target agent based on the device quantity dictionary, whether the target accelerator card device has multiple chips; If the target accelerator card device has multiple chips, a PCIe switch corresponding to the target accelerator card device is determined, and a PCI address corresponding to the PCIe switch is determined as the target PCI address corresponding to the target accelerator card.

8. An accelerator card device configuration device, characterized in that: Applied to the server, including: A parameter verification module is configured to utilize a target application programming interface to obtain a target configuration creation request corresponding to a target accelerator card device sent by a user terminal, and to perform target parameter verification on the target configuration creation request based on a pre-configured target data table; the target data table is a data table configured in a target component of OpenStack heterogeneous device management; the target parameter verification includes request permission verification and configuration information verification; a driver configuration data saving module, configured to, if the target configuration creation request passes the target parameter verification, use a target agent to determine a target driver component corresponding to the target accelerator card device based on the target configuration creation request, and use a target service to save the target configuration data corresponding to the target driver component to a target database; A device information saving module is used to use the target agent to obtain the target configuration data from the target database, parse the target configuration data to determine a target device list, determine the target driver component based on the target device list, initialize the target accelerator card device in the target device list using the target driver component, and use the target service to save the device information corresponding to the target accelerator card device to the target database.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the accelerator card device configuration method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that Used to store a computer program, wherein when the computer program is executed by a processor, the accelerator card device configuration method according to any one of claims 1 to 7 is implemented.

Images