Methods and electronic devices for accelerating target business

Abstract

This application provides a method and electronic device for accelerating a target service, relating to the field of virtualization technology. The method allows an electronic device to determine a target accelerator and a target acceleration strategy matching the target service based on the accelerator type and virtualization information. The electronic device then configures the target accelerator according to the target acceleration strategy to enable the target accelerator to process at least one sub-service within the target service. Using this method, the electronic device can fully utilize its hardware resources through virtualization technology without requiring hardware updates, thereby accelerating the target service (such as 4G LTE communication services and / or 5G NR communication services), improving the target service implementation capability and the upgrade capability of the electronic device.

Description

Technical Field

[0001] This application relates to the field of virtualization technology, and more particularly to a method and electronic device for accelerating target services. Background Technology

[0002] With the continuous development of terminal technology, the functional requirements of mobile terminals are becoming increasingly complex, necessitating more frequent upgrades to enhance their capabilities. However, these capability improvements are tightly coupled with hardware. For example, a mobile terminal's communication capabilities depend on its hardware architecture; updates to the hardware architecture improve its communication capabilities. Furthermore, communication capabilities are often isolated from computing and sensing capabilities. If all three capabilities need improvement, significant hardware upgrades are required, leading to substantial electronic waste and resource waste. Moreover, with Denard's Law becoming less effective and Moore's Law fading, the pace of hardware capability improvements is slowing. Upgrading mobile terminals through comprehensive hardware updates is becoming increasingly costly in terms of both economy and time.

[0003] Terminal virtualization is a new development model for mobile terminals. How to make full use of the hardware resources of mobile terminals through virtualization technology is an urgent problem to be solved. Summary of the Invention

[0004] To address the aforementioned technical issues, this application provides a method and electronic device for accelerating target services. This method enables the electronic device to fully utilize its hardware resources through virtualization technology without requiring hardware updates, thereby accelerating target services (such as 4G LTE communication services and / or 5G NR communication services), improving the implementation capability of target services and the upgrade capability of the electronic device.

[0005] In a first aspect, this application provides a method for accelerating a target service, applied to a first electronic device. The method includes: obtaining first hardware information of the first electronic device, the first hardware information including: the type of each accelerator in the first electronic device and virtualization information of each accelerator, the type of accelerator including: general-purpose processor type, dedicated accelerator type and coprocessor type, the virtualization information being used to indicate the virtualization method supported by the accelerator; determining a first target accelerator and a first acceleration strategy matching the target service based on the first hardware information, the first acceleration strategy being used to instruct the first electronic device to configure the first target accelerator; configuring the first target accelerator according to the first acceleration strategy, so that the first target accelerator processes at least one sub-service in the target service.

[0006] Thus, the first electronic device can be a mobile terminal, such as a mobile phone, wristband, watch, or tablet. The first electronic device configures the first target accelerator according to a determined first target acceleration strategy. This example utilizes virtualization technology to process the accelerator, enabling it to be invoked by at least one sub-service within the target service. Due to the accelerator's high processing speed, it accelerates the target service without requiring additional hardware resources, fully utilizing the electronic device's existing hardware resources, reducing the cost of accelerating the target service, and improving the electronic device's upgrade capabilities. Furthermore, in this example, based on different accelerator types and virtualization information, a first target accelerator and a first acceleration strategy suitable for the current target service can be selected, expanding the application scenarios for accelerating the target service and enhancing the electronic device's ability to implement the target service.

[0007] According to the first aspect, based on the first hardware information, a first target accelerator and a first acceleration strategy matching the target service are determined, including: determining the type of accelerator in the first target accelerator based on the type of each accelerator; and determining the first target accelerator and the first acceleration strategy based on the type of accelerator in the first target accelerator and virtualization information. In this way, different accelerators support different virtualization methods, allowing the first electronic device to select a suitable accelerator as the first target accelerator based on its type, rather than using a fixed virtualization method, thus improving the flexibility of accelerating the target service.

[0008] According to the first aspect, determining the type of accelerator in the first target accelerator based on the type of each accelerator includes: detecting whether the accelerator of the first electronic device has a dedicated accelerator type; if a dedicated accelerator type is detected, then the accelerator types in the first target accelerator include dedicated accelerator types and general-purpose processor types; if no dedicated accelerator type is detected, then detecting whether the accelerator of the first electronic device has a coprocessor type; if a coprocessor type is detected, then the accelerator types in the first target accelerator include coprocessor types and general-purpose processor types; if neither a dedicated accelerator type nor a coprocessor type is detected, then the accelerator types in the first target accelerator include general-purpose processor types. In this way, the computational speed of a dedicated accelerator is faster than that of a coprocessor, and the computational speed of a coprocessor is faster than that of a general-purpose processor. Prioritizing dedicated processors can further improve the acceleration speed of the target service.

[0009] According to the first aspect, determining the first target accelerator and the first acceleration strategy based on the type of accelerator in the first target accelerator and the virtualization information includes: if the accelerator type in the first target accelerator includes a dedicated accelerator type and a general-purpose processor type, then obtaining the virtualization information of each dedicated accelerator; based on the virtualization information of each dedicated accelerator, detecting whether there is a dedicated accelerator that supports the single root virtualization SRIOV method; if a dedicated accelerator that supports the SRIOV method is detected, then determining that the first target accelerator includes a first accelerator and a general-purpose processor, and determining that the first acceleration strategy includes a first strategy, and the first accelerator is a dedicated accelerator that supports the SRIOV method; if no dedicated accelerator that supports the SRIOV method is detected and the number of dedicated accelerators is greater than or equal to 1, then determining that the first target accelerator includes at least one second accelerator, and determining that the first acceleration strategy includes a second strategy, and the second accelerator is a dedicated accelerator that does not support the SRIOV method. In this way, the SRIOV method is simple and fast for virtualizing dedicated accelerators, and it can be flexibly configured to add or remove functions that need to be accelerated in the target business (such as adding or removing functions that need to be accelerated); while for dedicated accelerators that do not support the SRIOV method, the dedicated accelerator can be virtualized by binding it to a container, thus avoiding the problem that dedicated accelerators that do not support the SRIOV method cannot be virtualized.

[0010] According to the first aspect, the configuration of a first target accelerator according to a first acceleration strategy includes: if the first acceleration strategy includes a first strategy, configuring the first accelerator in an SRIOV manner; creating at least one container in a general-purpose processor for at least one sub-service in the first target service; binding the container containing the target function in the at least one sub-service to at least one virtual function (VF) in the first accelerator; and installing target driver software in the container containing the target function. If the first acceleration strategy includes a second strategy, creating at least one container in a general-purpose processor for at least one sub-service in the first target service; binding the container containing the target function in the at least one sub-service to at least one second accelerator; and installing target driver software in the container containing the target function. In this way, by configuring a dedicated accelerator in an SRIOV manner and installing target driver software in the corresponding container containing the target function, the container containing the target function can call the dedicated accelerator to accelerate the processing of the target function. The target function can be a function with high real-time requirements; other functions with low real-time requirements are implemented in the general-purpose processor. This first strategy accelerates the target service quickly.

[0011] According to the first aspect, the first target accelerator and the first acceleration strategy are determined based on the type of accelerator and virtualization information in the first target accelerator, including: if the accelerator type in the first target accelerator includes a coprocessor type and a general-purpose processor type, then the acceleration capability of the coprocessor is obtained; the current hardware acceleration requirements are obtained, including the computing power of the hardware required by the target function; if it is determined that the acceleration capability meets the hardware acceleration requirements, then the first acceleration strategy is determined based on the virtualization information of the coprocessor; if it is determined that the acceleration capability does not meet the hardware acceleration requirements, then the first acceleration strategy is determined to include a pass-through virtualization strategy. Thus, when the acceleration capability of the coprocessor does not meet the hardware acceleration requirements, a pass-through virtualization approach can be used, that is, the coprocessor is bound to the container where a certain target function resides, and the remaining functions can be implemented by a general-purpose processor; when the acceleration capability of the coprocessor meets the hardware acceleration requirements, the coprocessor can select an appropriate virtualization method based on its own virtualization information to improve the acceleration speed of the target function.

[0012] According to the first aspect, based on the coprocessor's virtualization information, a first acceleration strategy is determined, including: if the coprocessor is detected to support SRIOV, then the first acceleration strategy includes a third strategy; if the coprocessor is detected to not support SRIOV and is not a preset model, then the first acceleration strategy includes a fourth strategy; if the coprocessor is detected to be a preset model, then the first acceleration strategy includes a fifth strategy. In this way, the most suitable acceleration strategy is adaptively selected based on the coprocessor's model or whether it supports SRIOV, improving the flexibility of accelerating the target service.

[0013] According to the first aspect, the target accelerator is configured according to the first acceleration strategy, including: if the first acceleration strategy includes a third strategy, the coprocessor is configured in the manner of SRIOV; at least one container is created in the general-purpose processor for at least one sub-service of the first target service; the container containing the target function of the at least one sub-service is bound to at least one virtual function (VF) in the coprocessor; target driver software is installed in the container containing the target function; if the first acceleration strategy includes a fourth strategy, at least one container is created in the general-purpose processor for at least one sub-service of the first target service; the container containing the target function of the first sub-service is bound to the coprocessor; target driver software is installed in the container containing the target function; shared memory is created in the host system, and the container containing the target function forwards instructions to other containers through the shared memory so that other containers can call the coprocessor. In this way, the third strategy can flexibly configure the coprocessor according to the target function that needs to be accelerated; by adopting the fourth strategy, instructions can be forwarded through shared memory, and the coprocessor can be called, avoiding the problem of the coprocessor not being able to be virtualized.

[0014] According to the first aspect, if the target service is a target communication service, and the target communication service includes at least one communication standard; in the general-purpose processor, at least one container is created for at least one sub-service in the first target service, including: allocating a corresponding container for each communication standard; or, allocating a corresponding container for each protocol layer of each communication standard; or, allocating a corresponding container for each preset protocol layer of each communication standard, and allocating a shared container for protocol layers other than the preset protocol layers. This allows for flexible container creation, improving the flexibility of accelerating the target communication service.

[0015] According to the first aspect, the target functions include: physical layer functions, and / or, media access layer functions. Thus, the target functions are those with high real-time requirements, and acceleration can significantly speed up communication services.

[0016] According to the first aspect, the method further includes: when a failure of the first target accelerator is detected or the acceleration capability of the first target accelerator is detected as not meeting the current hardware acceleration requirements, the step of obtaining the first hardware information of the first electronic device is re-executed. Thus, when a failure of the first target accelerator or the acceleration capability of the first target accelerator does not meet the current hardware acceleration requirements, the step of obtaining the first hardware information is re-executed, and the first target accelerator is re-determined, thereby achieving backup for target service acceleration.

[0017] According to the first aspect, before installing the target driver software on the container where the target function resides, the method further includes: sending a loading request to a second electronic device, wherein the second electronic device queries the installation package of the target driver software and sends the installation package of the target driver software to the first electronic device; and receiving the installation package of the target driver software. In this way, the target driver software is stored by the second electronic device (such as a server), reducing the storage space occupied by the target driver software on the first electronic device.

[0018] Secondly, this application provides a method for accelerating a target service, applied to a first electronic device, comprising: acquiring first hardware information of the first electronic device, the first hardware information including: the type of each accelerator in the first electronic device and virtualization information of each accelerator, the accelerator type including: general-purpose processor type, dedicated accelerator type and coprocessor type, the virtualization information being used to indicate the virtualization method supported by the accelerator; sending a first acceleration request to a second electronic device, the first acceleration request including the first hardware information and information of the target service; the second electronic device determining a first target accelerator and a first acceleration strategy matching the target service based on the first hardware information, the first acceleration strategy including instructions for the first electronic device to configure the first target accelerator; acquiring information of the first target accelerator and the first acceleration strategy from the second electronic device; configuring the first target accelerator according to the first acceleration strategy, so that the first target accelerator processes at least one sub-service in the first target service.

[0019] In this way, the first electronic device (such as a mobile phone) sends the first hardware information to the second electronic device (such as a server). The second electronic device determines the first target accelerator and the first acceleration strategy for the target service based on the first hardware information. The server then sends the first acceleration strategy to the first electronic device. This method, in which the second electronic device determines the first target accelerator and the first acceleration strategy, allows for easy updates to the first acceleration strategy and the method of determining the first target accelerator, further improving the flexibility of accelerating the target service.

[0020] According to the second aspect, the first target accelerator is configured according to the first acceleration strategy, including: if the first acceleration strategy includes the first strategy, the first accelerator is configured according to the single root virtualization SRIOV method, and the first accelerator is a dedicated accelerator that supports SRIOV; at least one container is created on the general-purpose processor for at least one sub-service in the target service; the container where the target function in at least one sub-service is located is bound to at least one virtual function (VF) in the first accelerator; and the target driver software is installed on the container where the target function is located. If the first acceleration strategy includes the second strategy, at least one container is created in the general-purpose processor for at least one sub-service of the target service; the container containing the target function of the at least one sub-service is bound to at least one second accelerator, which is a dedicated accelerator that does not support SRIOV; the target driver software is installed in the container containing the target function. If the first acceleration strategy includes the third strategy, the coprocessor is configured according to SRIOV; at least one container is created in the general-purpose processor for at least one sub-service of the target service; the container containing the target function of the at least one sub-service is bound to at least one virtual function (VF) in the coprocessor; the target driver software is installed in the container containing the target function. If the first acceleration strategy includes the fourth strategy, at least one container is created in the general-purpose processor for at least one sub-service; the container containing the target function of the at least one sub-service is bound to the coprocessor; the target driver software is installed in the container containing the target function; shared memory is created in the host system, and the container containing the target function forwards instructions to other containers through the shared memory. If the first acceleration strategy includes the fifth strategy, a toolkit for the target function is added to the coprocessor. Thus, different first acceleration strategies result in different accelerator configuration processes, allowing the configured accelerators to accelerate the target service.

[0021] According to the second aspect, the method further includes: when a failure of the first target accelerator is detected or the acceleration capability of the first target accelerator is detected as not meeting the current hardware acceleration requirements, then the first hardware information of the first electronic device is reacquired; a second acceleration request is sent to the second electronic device, the second acceleration request including: information of the target service and new first hardware information; the second electronic device determines a second target accelerator and a second acceleration strategy matching the target service based on the new first hardware information, the second acceleration strategy including instructions for the first electronic device to configure the second target accelerator; information of the second target accelerator and the corresponding second acceleration strategy are obtained from the second electronic device; the second target accelerator is configured according to the second acceleration strategy so that the second target accelerator processes at least one sub-service in the target service. Thus, when the first target accelerator fails or its acceleration capability does not meet the current hardware acceleration requirements, the second electronic device reacquires the first hardware information and redetermines the second target accelerator and the second target acceleration strategy, thereby achieving backup for the target service acceleration.

[0022] Thirdly, this application provides a method for accelerating a target service, applied to a second electronic device, comprising: receiving a first acceleration request sent by a first electronic device, the first acceleration request including first hardware information of the first electronic device and information of the target service, the first hardware information including the type of each hardware accelerator in the first electronic device and virtualization information of each accelerator, the type of hardware accelerator including: general-purpose processor type, dedicated accelerator type and coprocessor type, the virtualization information being used to indicate the virtualization method supported by the accelerator; determining a first target accelerator and a first acceleration strategy matching the target service based on the first hardware information; sending first feedback information to the first electronic device, the first feedback information including information of the first target accelerator and information of the first acceleration strategy; the first electronic device obtaining the information of the first target accelerator and the first acceleration strategy from the second electronic device, and the first electronic device configuring the first target accelerator according to the first acceleration strategy, so that the first target accelerator processes at least one sub-service in the first target service.

[0023] In this way, the first electronic device (such as a mobile phone) sends the first hardware information to the second electronic device (such as a server). The second electronic device determines the first target accelerator and the first acceleration strategy for the target service based on the first hardware information. The server then sends the first acceleration strategy to the first electronic device. This method, in which the second electronic device determines the first target accelerator and the first acceleration strategy, allows for easy updates to the first acceleration strategy and the method of determining the first target accelerator, further improving the flexibility of accelerating the target service.

[0024] According to the third aspect, based on the first hardware information, a first target accelerator and a first acceleration strategy matching the target service are determined, including: determining the type of accelerator in the first target accelerator based on the type of each accelerator; and determining the first target accelerator and the first acceleration strategy based on the type of accelerator in the first target accelerator and the virtualization information.

[0025] According to the third aspect, determining the type of accelerator in the first target accelerator based on the type of each accelerator includes: detecting whether the accelerator of the first electronic device has a dedicated accelerator type based on the type of each accelerator; if a dedicated accelerator type is detected, determining that the accelerator types in the first target accelerator include dedicated accelerator types and general-purpose processor types; if no dedicated accelerator type is detected, detecting whether the accelerator of the first electronic device has a coprocessor type; if a coprocessor type is detected, determining that the accelerator types in the first target accelerator include coprocessor types and general-purpose processor types; if neither a dedicated accelerator type nor a coprocessor type is detected, determining that the accelerator types in the first target accelerator include general-purpose processor types.

[0026] According to the third aspect, based on the type of accelerators and virtualization information in the first target accelerator, the first target accelerator and the first acceleration strategy are determined, including: if the accelerator types in the first target accelerator include dedicated accelerator types and general-purpose processor types, then the virtualization information of each dedicated accelerator is obtained; based on the virtualization information of each dedicated accelerator, it is detected whether there is a dedicated accelerator supporting the single root virtualization SRIOV method; if a dedicated accelerator supporting the SRIOV method is detected, then the first target accelerator is determined to include a first accelerator and a general-purpose processor, and the first acceleration strategy is determined to include a first strategy, wherein the first accelerator is a dedicated accelerator supporting the SRIOV method; if no dedicated accelerator supporting the SRIOV method is detected and the number of dedicated accelerators is greater than or equal to 1, then the first target accelerator is determined to include at least one second accelerator, and the first acceleration strategy is determined to be a dedicated accelerator supporting the SRIOV method. The acceleration strategy includes a second strategy, where the second accelerator is a dedicated accelerator that does not support the SRIOV method. The first strategy is used to: instruct the first electronic device to configure the first accelerator according to the SRIOV method; instruct the first electronic device to create at least one container in a general-purpose processor for at least one sub-service of the first target service; instruct the first electronic device to bind the container containing the target function of at least one sub-service to at least one virtual function (VF) in the first accelerator; and instruct the first electronic device to install target driver software in the container containing the target function. The second strategy is used to: instruct the first electronic device to create at least one container in a general-purpose processor for at least one sub-service of the first target service; instruct the first electronic device to bind the container containing the target function of at least one sub-service to at least one first accelerator; and instruct the first electronic device to install target driver software in the container containing the target function. In this way, the second electronic device determines the first target accelerator and the corresponding first acceleration strategy suitable for the current first electronic device based on the different types of accelerators in the first electronic device and the virtualization information of the accelerators, thereby improving the speed of accelerating the target service and increasing the flexibility and accuracy of determining the first target accelerator and the first acceleration strategy.

[0027] According to the third aspect, based on the type of accelerator in the first target accelerator and the virtualization information, the first target accelerator and the first acceleration strategy are determined, including: if the accelerator type in the first target accelerator includes a coprocessor type and a general-purpose processor type, then the acceleration capability of the general-purpose processor is obtained; the current hardware acceleration requirements are obtained, including the computing power of the hardware required by the target function; if it is determined that the acceleration capability meets the hardware acceleration requirements, then the first acceleration strategy is determined based on the virtualization information of the coprocessor; if it is determined that the acceleration capability does not meet the hardware acceleration requirements, then the first acceleration strategy is determined to include a pass-through virtualization strategy. Thus, when the acceleration capability of the coprocessor does not meet the hardware acceleration requirements, the second electronic device can determine that the acceleration strategy adopts a pass-through virtualization method, that is, binding the coprocessor to the container where a certain target function resides, while other functions can be implemented by the general-purpose processor; when the acceleration capability of the coprocessor meets the hardware acceleration requirements, the coprocessor can select an appropriate virtualization method based on its own virtualization information to improve the acceleration speed of the target function.

[0028] According to the third aspect, based on the coprocessor's virtualization information, a first acceleration strategy is determined, including: if the coprocessor's virtualization information indicates that the coprocessor supports SRIOV, then the first acceleration strategy includes a third strategy; the third strategy is used to: instruct the first electronic device to configure the coprocessor in SRIOV mode; instruct the first electronic device to create at least one container in a general-purpose processor for at least one sub-service in a first target service; instruct the first electronic device to bind the container containing the target function in at least one sub-service to at least one virtual function (VF) in the coprocessor; instruct the first electronic device to install target driver software in the container containing the first target function; if the coprocessor's virtualization information indicates that the coprocessor does not support SRIOV mode, and the coprocessor is not a pre-... If the model is specified, then the first acceleration strategy includes a fourth strategy. The fourth strategy is used to: instruct the first electronic device to create at least one container for at least one sub-service in the general-purpose processor; instruct the first electronic device to bind the container containing the target function in at least one sub-service to the coprocessor; instruct the first electronic device to install target driver software for the container containing the first target function; instruct the first electronic device to create shared memory in the host system, and the container containing the target function forwards instructions to other containers through the shared memory so that other containers can call the coprocessor; the container containing the target function transmits the data processed by the coprocessor back to the other containers through the shared memory; if the virtualization information of the coprocessor indicates that the coprocessor belongs to a preset model, then the first acceleration strategy includes a fifth acceleration strategy. In this way, the second electronic device can adaptively select the most suitable acceleration strategy according to the model of the coprocessor or whether it supports SRIOV mode, which improves the flexibility of accelerating the target service.

[0029] According to the third aspect, the method further includes: receiving a second acceleration request sent by a first electronic device, the second acceleration request including: information about a target service and new first hardware information, the second acceleration request being sent by the first electronic device when it detects a failure in the first target accelerator or when it detects that the acceleration capability of the first target accelerator does not meet the current hardware acceleration requirements of the first electronic device; determining a second target accelerator and a second acceleration strategy matching the target service based on the new first hardware information, the second acceleration strategy including instructions for the first electronic device to configure the second target accelerator; sending the information about the second target accelerator and the second acceleration strategy to the first electronic device, and configuring the second target accelerator according to the second acceleration strategy so that the second target accelerator processes at least one sub-service in the second target service. Thus, when a second acceleration request is received, the second electronic device can re-determine the second target accelerator and the second acceleration strategy for the first electronic device, avoiding the problem that the first electronic device cannot accelerate the target service due to a failure in the first target accelerator or the acceleration capability of the first target accelerator not meeting the current hardware acceleration requirements of the first electronic device.

[0030] Fourthly, this application provides an electronic device, including: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and when the computer programs are executed by the one or more processors, the electronic device performs the method for accelerating a target service corresponding to the first aspect and any implementation thereof, or performs the method for accelerating a target service corresponding to the second aspect and any implementation thereof, or performs the method for accelerating a target service corresponding to the third aspect and any implementation thereof.

[0031] The fourth aspect and any implementation thereof correspond to the first aspect and any implementation thereof, or to the second aspect and any implementation thereof, or to the third aspect and any implementation thereof. The technical effects corresponding to the fourth aspect and any implementation thereof are similar to those corresponding to the first aspect and any implementation thereof, and will not be repeated here.

[0032] Fifthly, this application provides a computer-readable medium for storing a computer program that, when the computer program is run on an electronic device, causes the electronic device to execute the method for accelerating a target service corresponding to the first aspect and any implementation thereof, or to execute the method for accelerating a target service corresponding to the second aspect and any implementation thereof, or to execute the method for accelerating a target service corresponding to the third aspect and any implementation thereof. Attached Figure Description

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

[0034] Figure 1 This is an exemplary schematic diagram of the structure of an electronic device;

[0035] Figure 2 This is a flowchart illustrating an exemplary method for accelerating a target service;

[0036] Figure 3 This is a flowchart illustrating an example of a first electronic device accelerating communication services;

[0037] Figure 4 This is an exemplary flowchart illustrating how a mobile phone determines an acceleration strategy;

[0038] Figure 5 This is a schematic diagram of the first target accelerator after configuration, as exemplarily shown;

[0039] Figure 6 This is a schematic diagram of another first target accelerator with complete configuration, as exemplarily shown;

[0040] Figure 7 This is an exemplary flowchart illustrating the acceleration capabilities and hardware acceleration requirements based on the coprocessor, used to accelerate a target function.

[0041] Figure 8 This is an example illustrating a process of virtualizing a GPU;

[0042] Figure 9 This is a schematic diagram of another first target accelerator with complete configuration, as exemplarily shown;

[0043] Figure 10 This is a schematic diagram of another first target accelerator with complete configuration, as exemplarily shown;

[0044] Figure 11 This is an example of an interaction diagram between a mobile terminal and a server;

[0045] Figure 12 This is an exemplary flowchart illustrating how a mobile terminal malfunctions, the target accelerator is re-identified, and the accelerator is reconfigured.

[0046] Figure 13This is an exemplary flowchart of how to redetermine the target accelerator and reconfigure the accelerator when the acceleration capability of the first target accelerator does not meet the hardware acceleration requirements.

[0047] Figure 14 This is an example of another interaction diagram between a mobile terminal and a server. Detailed Implementation

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

[0049] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0050] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

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

[0052] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0053] Since performance improvements in mobile terminals are based on hardware upgrades, this increases both time and economic costs. This application provides a method for accelerating target services. Electronic devices can utilize virtualization technology to virtualize the target accelerator based on its type, allowing the device to leverage different hardware capabilities to accelerate target services. By using virtualization technology, the device fully utilizes its hardware resources without requiring additional hardware, thus improving processing speed. Furthermore, by employing virtualization technology tailored to different hardware conditions, the application scenarios for accelerating target services are expanded.

[0054] In this example, the electronic device can be a mobile phone, tablet, watch, smart camera, or other similar device.

[0055] Figure 1 This is a schematic diagram illustrating the structure of an electronic device 100 according to an embodiment of this application. It should be understood that... Figure 1 The electronic device 100 shown is merely an example of an electronic device, and the electronic device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. Figure 1 The various components shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0056] Electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.

[0057] Figure 2This is a flowchart illustrating a method for accelerating a target service, as exemplified. The method, performed by a first electronic device, includes the following specific steps:

[0058] Step 201: The first electronic device acquires the first hardware information of the first electronic device.

[0059] For example, when the first electronic device receives an instruction to query hardware information, it obtains the hardware information (i.e., the first hardware information) of the first electronic device. This first hardware information may include the type of accelerator configured in the first electronic device, wherein the accelerator type includes: general-purpose processor type, dedicated accelerator type, and coprocessor type. General-purpose processor type accelerators include: Central Processing Unit (CPU). Dedicated accelerator type accelerators include: Field Programmable Gate Array (FPGA) and Application Specific Integrated Circuit (ASIC). Coprocessor type accelerators include: Graphics Processing Unit (GPU) and Neural Processor Unit (NPU).

[0060] Optionally, the first hardware information may also include information on the processing power of each accelerator. The processing power of an accelerator can be understood as its computing power. For example, the processing power information of a CPU may include clock speed, number of cores, and floating-point operation power (i.e., the number of floating-point operations per core per second). The processing power information of a coprocessor (such as a GPU or NPU) may include clock speed, number of cores, and floating-point operation power (i.e., the number of floating-point operations per core per second). The processing power information of a dedicated accelerator (such as an FPGA or ASIC) may include the number of adders, frequency, and other information.

[0061] Optionally, the first hardware information may also include virtualization capability information for each accelerator. The virtualization methods of accelerators from different manufacturers may be different, and the degree of virtualization (which can be understood as the number of virtual logical devices allowed) that can be achieved by different versions of accelerators from the same manufacturer may also be different. Therefore, the virtualization capability information in this example may include the manufacturer and version information of the accelerator, or information such as whether the accelerator supports SR-IOV.

[0062] Table 1 shows the contents of the first hardware information as an example:

[0063] Table 1

[0064]

[0065] The processing power of an accelerator can be quantified by its computing power. For example, the computing power of a general-purpose processor and a coprocessor = number of cores * clock speed * floating-point operations per core per second.

[0066] A dedicated accelerator can include different adders, and the processing power of the dedicated accelerator is equal to the sum of the processing powers of the different adders. The processing power of each adder = number of adders * frequency. For example, dedicated accelerator A includes digital signal processing (DSP) adders and logic adders. The processing power of dedicated accelerator A = number of DSP adders * frequency + number of logic adders * frequency.

[0067] In some embodiments, the first electronic device can be triggered to acquire current hardware information upon receiving a hardware information acquisition instruction input by the user. For example, if a mobile phone has a target service acceleration application installed, a hardware information acquisition instruction can be generated when the user clicks the application icon. Optionally, the first electronic device can also generate hardware information acquisition instructions periodically, with the period lasting for one month, six months, one year, two years, or longer.

[0068] Optionally, when the first electronic device detects a change in the current hardware, it can generate a hardware information acquisition instruction. For example, taking a mobile phone as an example, when the mobile phone is replaced with a new FPGA, the first electronic device can regenerate a hardware information acquisition instruction when it detects the identifier of the new FPGA, in order to reacquire the current hardware information of the mobile phone.

[0069] It can be understood that the hardware information of the first electronic device is a local resource. The first electronic device responds to the hardware information acquisition instruction, reads the status of each hardware module, and thus obtains the hardware information of the first electronic device.

[0070] Step 202: The first electronic device determines the first target accelerator that matches the first target service based on the first hardware information.

[0071] For example, the first electronic device can accelerate the processing of various services, such as communication services, computing services, and sensing services. Communication services include communication services of different standards, such as 4G LTE (Long Term Evolution), 5G NR (New Radio), Wi-Fi, etc. Computing services may include image rendering, etc. Sensing services may include target positioning, etc. The user can input the target service to be accelerated into the first electronic device. For example, the phone displays a service acceleration application interface, and the user can click (or check) the option corresponding to the communication service on the display screen. The phone responds to the user's click operation and determines that the first target service of the phone is a communication service.

[0072] Different types of accelerators have different computing speeds, and the order of computing speed from fastest to slowest is: dedicated accelerator, coprocessor, general-purpose processor. The first electronic device can determine the first target accelerator that matches the first target service based on the type of accelerator. The first target accelerator may include one accelerator or multiple (i.e., two or more) different accelerators.

[0073] In some embodiments, the first electronic device detects whether a dedicated accelerator type accelerator exists in the current device. If the first electronic device detects the existence of a dedicated accelerator type accelerator, it determines that the first target accelerator includes a dedicated accelerator and a general-purpose processor. If the first electronic device detects that no dedicated accelerator type accelerator exists, it detects whether a coprocessor type accelerator exists in the current device. If the first electronic device detects the existence of a coprocessor type accelerator, it determines that the first target accelerator includes a coprocessor and a general-purpose processor. If the first electronic device detects that no coprocessor type accelerator exists, it determines that the first target accelerator includes a general-purpose processor.

[0074] In this example, the first electronic device prioritizes accelerating the target service using a dedicated accelerator and a general-purpose processor. When a dedicated accelerator is unavailable, a coprocessor and a general-purpose processor accelerate the target service. If neither a dedicated accelerator nor a coprocessor is available, the target service can be accelerated solely using the general-purpose processor. The first electronic device, based on its current hardware and the accelerators' computing speeds, prioritizes selecting the fastest accelerator, ensuring that the chosen target accelerator processes the target service at the fastest speed available on the device, thus improving processing speed. Furthermore, by adaptively selecting the fastest accelerator for the target service based on its accelerator type, the first electronic device enhances the intelligence of its target service acceleration process.

[0075] Step 203: The first electronic device acquires a first acceleration strategy that matches the first target accelerator.

[0076] Specifically, the target service is accelerated by the first target accelerator; that is, different services need to share the first target accelerator. In this example, virtualization technology can be used to achieve the goal of different services sharing the first target accelerator. Virtualization technology is a technology that abstracts and recombines computer system hardware, and a virtualization software layer runs between the computer hardware platform and the operating system. This virtualization software layer is generally called a hypervisor, which can enable multiple operating systems to run arbitrarily on multiple computer hardware platforms.

[0077] Different accelerators support different virtualization methods. The first electronic device can determine a matching first acceleration strategy based on the virtualization capabilities of the first target accelerator. The first acceleration strategy instructs the first electronic device on how to configure the first target accelerator. For example, when the first electronic device detects that a dedicated accelerator supports SRIOV, it determines to adopt the first strategy. This first strategy instructs the first electronic device to configure the dedicated accelerator according to the SRIOV method, instructs the first electronic device to create at least one container for the sub-services of the first target service in the general-purpose processor, instructs the first electronic device to bind at least one virtual function (VF) to each target container, and installs target driver software in the target container. Here, the target container is a container containing the target function, and the target function is the function that needs to be accelerated in at least one sub-service of the first target service. For example, the physical layer function in a 4G LTE communication service is a target function; the computing function in an image processing service is a target function.

[0078] It should be noted that the first target service can have multiple sub-services or only one. For example, the communication service can include 4G LTE communication services (i.e., each communication standard's communication service is a sub-service) and 5G NR communication services. The sub-service in the computing service is: image rendering.

[0079] Each sub-service may include one or more functions. For example, 5G NR communication services include the functions of a 7-layer protocol, and can target functions of protocol layers with real-time requirements, such as the lower physical layer, higher physical layer, and lower media access layer. Image computing services include image rendering.

[0080] In this example, the first electronic device determines a suitable acceleration strategy by utilizing the virtualization capabilities of the accelerator contained in the first target accelerator, so as to make full use of the computing power of the current accelerator.

[0081] The following sections of this application will use communication services as an example to illustrate in detail how to determine the matching acceleration strategy based on the virtualization capabilities of the accelerator in the first target accelerator.

[0082] Step 204: The first electronic device configures the first target accelerator according to the first acceleration strategy so that the first target accelerator processes at least one sub-service in the first target service.

[0083] For example, a first electronic device configures a first target accelerator according to a first acceleration strategy, so that the first target accelerator processes at least one sub-service in a first target service. For example, when the target service is a communication service, the sub-services of the communication service include: 4G LTE, 5G NR, Wi-Fi, etc. The computing service includes sub-services such as image rendering, and the perception service includes sub-services such as target positioning.

[0084] In this example, the first electronic device determines a first target accelerator for the first target service based on the type of accelerator; and determines a first acceleration strategy matching the first target accelerator, thereby enabling the first target accelerator to process the first target service and accelerate it. Because the electronic device can automatically determine the target accelerator and acceleration strategy that match the first target service based on the type of accelerator, this acceleration method can be applied to different electronic devices, increasing its applicability across various scenarios.

[0085] The first target service in this application takes the communication service of a mobile terminal as an example. Communication services of electronic devices have high real-time requirements, necessitating hardware accelerators for acceleration. Different types of devices use different types of accelerators; for example, device A has a dedicated accelerator, device B has a coprocessor, and device C only has a general-purpose processor (such as a CPU). This example will specifically illustrate the process by which the first electronic device accelerates the communication service.

[0086] Figure 3 This is a schematic diagram illustrating how a first electronic device accelerates communication services. In this example, a mobile phone is used as the first electronic device.

[0087] Step 301: The first electronic device acquires the first hardware information of the first electronic device.

[0088] This step is largely the same as step 201. The process of obtaining the first hardware information of the first electronic device can be referred to the relevant description in step 201, and will not be repeated here.

[0089] Step 302: The first electronic device determines whether a dedicated accelerator type accelerator exists in the first electronic device based on the first hardware information. If it is determined that a dedicated accelerator type accelerator exists, then the first target accelerator is determined to include a dedicated accelerator and a general-purpose processor, and step 303 is executed. If it is determined that no dedicated accelerator type accelerator exists, then step 305 is executed.

[0090] For example, the mobile phone can obtain the type of each accelerator, determine whether there is a dedicated accelerator type in the mobile phone, and if so, determine that the first target accelerator includes a dedicated accelerator and a general-purpose processor. If not, proceed to step 305.

[0091] Step 303: A dedicated accelerator in the first electronic device accelerates the physical layer, enabling adaptive virtualization.

[0092] For example, dedicated accelerators offer high computational speeds and can be used to accelerate functions with high real-time requirements, such as all or part of the physical layer functions in 4G LTE, and MAC layer functions. In this example, a dedicated accelerator can be used to accelerate (i.e. process) some physical layer functions in the 4G LTE communication standard and physical layer functions in the 5G NR communication standard.

[0093] The mobile phone can achieve adaptive virtualization based on the virtualization information of the dedicated accelerators within it. The phone obtains the virtualization information for each dedicated accelerator, including information about the virtualization methods supported by that accelerator (such as manufacturer, version number, etc.). The phone can then determine its acceleration strategy based on this virtualization information. Figure 4 As shown, it includes:

[0094] Step 401: The mobile phone detects whether there is a dedicated accelerator that supports the SRIOV method. If it is detected, proceed to step 402, that is, determine to adopt the first strategy. If it is detected that there is no dedicated accelerator that supports the SRIOV method, proceed to step 403, that is, determine to adopt the second strategy.

[0095] Based on the virtualization information of each dedicated accelerator, the mobile phone can detect whether there is a dedicated accelerator in the current mobile phone that supports the single root virtualization SRIOV method. If it exists, it can select one of the dedicated accelerators that support SRIOV as the first accelerator. The first accelerator is determined to accelerate some physical layer functions in the 4G LTE communication service, while the general processor accelerates other functions in the physical layer and other protocol layers in the 4G LTE communication service.

[0096] Step 402: The mobile phone determines to adopt the first strategy.

[0097] The mobile phone determines the acceleration strategy of the first target accelerator as the first strategy. This first strategy is used to instruct the mobile phone to configure the first accelerator in the manner of SRIOV; instruct the mobile phone to create at least one container in the second accelerator for at least one sub-service of the first target service; instruct the mobile phone to bind the container where the target function of at least one sub-service is located to at least one virtual function (VF) in the first accelerator; and instruct the mobile phone to install the target driver software in the container where the target function is located.

[0098] For example, if a mobile phone detects the existence of a dedicated accelerator that supports SRIOV, it determines that the first accelerator is that dedicated accelerator supporting SRIOV. SRIOV technology is implemented based on the PCIe specification, with physical resources interconnected with the CPU via the PCIe bus. In SRIOV technology, software integrates transmit and receive queues into the hardware, allowing direct access to the hardware from a virtual machine. The SRIOV protocol introduces two types of functions: Virtual Functions (VF) and Physical Functions (PF).

[0099] The mobile phone can determine the number of VFs in the first accelerator based on the number of sub-services, for example, such as... Figure 5 As shown, the target service (such as a communication service) includes two sub-services: a 4G LTE communication service and a 5G NR communication service. This dedicated accelerator is divided into at least two VFs.

[0100] Mobile phones can create corresponding containers for each communication standard's communication services within a general-purpose processor. For example, a mobile phone can create one container for each communication standard, meaning that seven layers can share a single container, such as... Figure 5 As shown, the general-purpose processor creates LTE and NR containers. The LTE container corresponds to the 4G LTE communication standard, and the NR container corresponds to the 5G NR communication standard. This general-purpose processor also includes a container engine (Docker). Docker is an open-source application container engine that allows developers to package applications and their dependencies into a portable image and deploy it to machines running operating systems such as Linux or Windows, enabling virtualization. The container library (libcontainer) is a separate container management package. The network driver (networkdriver) and the management driver (execdriver) both use libcontainer to perform specific operations on the containers. The networkdriver is used to create the network environment for Docker. The execdriver is used to limit the resources available to the Docker container or execute user commands.

[0101] The Physical Function (PF) driver is installed on the host machine of the general-purpose processor. This host PF driver is bound to the PF in the dedicated accelerator. Each container is bound to at least one VF. For example... Figure 5As shown, the 4G LTE container and the NR container are each bound to their respective VF. The PF driver is used to abstract a subset of physical resources such as send / receive queues into VF virtual function devices, and to map the VF devices to the 4G LTE container or the 5G NR container through the host kernel in a pass-through I / O device manner.

[0102] Since each container is a parallel process, each process can call its corresponding VF simultaneously. That is, each container can call a dedicated accelerator through its own VF to obtain the data processed by the dedicated accelerator.

[0103] Figure 5 The diagram illustrates the configuration of the first strategy, assuming that a dedicated accelerator is used to accelerate certain physical layer functions in the 4G LTE communication standard and to accelerate the processing of physical layer functions in the 5G NR communication standard. The mobile phone can create a corresponding container for each layer of the 4G communication standard service in the general-purpose processor; that is, there are seven containers for the 4G communication standard service. The container corresponding to the physical layer is denoted as the LTE container. This LTE container is bound to a VF (Vehicle Function) in the dedicated accelerator. When the 4G LTE physical layer needs to use data processed by the dedicated accelerator, the LTE container can call the corresponding VF to obtain the processed data. Other functions in the 4G LTE physical layer are implemented in the general-purpose processor.

[0104] The mobile phone can create corresponding containers for each protocol layer in the 5G NR communication standard (excluding the physical layer) within its general-purpose processor. Specifically, there are six containers for the 5G NR communication standard: MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer. Inter-layer communication can transmit data via PIC (Inter-Process Communication). The container corresponding to the physical layer is designated as the NR container. This NR container is bound to a VF (Vehicle Function) in a dedicated accelerator. When the MAC layer in 5G NR needs to obtain data from the physical layer, the NR container can call the corresponding VF to retrieve the physical layer data processed by the dedicated accelerator. Alternatively, when the MAC layer in 5G NR needs to transmit data to the physical layer, it sends the data to the dedicated accelerator via the VF. The dedicated accelerator then retrieves the data transmitted by the MAC layer and communicates with the physical layers of other devices.

[0105] Specifically, the target driver software for calling the corresponding VF is installed in the NR container, while the target driver software does not need to be installed in the containers corresponding to other layers.

[0106] Optionally, the NR container can also correspond to multiple VFs. For example, five VFs are created in the dedicated accelerator and labeled as VF-1, VF-2, VF-3, VF-4 and VF-5, respectively. Among them, the LTE container is bound to VF-1, the NR container is bound to VF-2, VF-3 and VF-4, and the Wi-Fi container is bound to VF-5.

[0107] In some embodiments, if the mobile phone detects the existence of multiple dedicated accelerators supporting SRIOV, it can select any one of these dedicated accelerators as the first accelerator. For example, if the mobile phone includes two dedicated accelerators supporting SRIOV, namely dedicated accelerator A and dedicated accelerator B, the mobile phone can select any one of the two dedicated accelerators as the first accelerator.

[0108] Optionally, if the mobile phone detects the existence of multiple dedicated accelerators supporting SRIOV, it can also select the dedicated accelerator with the highest computing power from among the multiple dedicated accelerators supporting SRIOV as the first accelerator. For example, if dedicated accelerator A and dedicated accelerator B both support SRIOV virtualization, and the mobile phone obtains the computing power 'a' of dedicated accelerator A and the computing power 'b' of dedicated accelerator B, where a > b, the mobile phone can select dedicated accelerator A as the first accelerator.

[0109] In this example, SRIOV technology is simple to configure and can be quickly and flexibly configured for different communication standards. For instance, when adding a Wi-Fi communication service, the phone can create a container corresponding to the Wi-Fi standard, add a Virtual Function (VF) in the first accelerator, and bind the added VF to the container corresponding to the Wi-Fi standard. The phone's configuration for the newly added Wi-Fi communication service is flexible. Furthermore, due to the high computing speed of the dedicated accelerator, the target functions within the target service are accelerated, improving the speed of communication service acceleration.

[0110] Step 403: The mobile phone determines to adopt the second strategy.

[0111] In some embodiments, when a dedicated accelerator does not support SRIOV virtualization, passthrough virtualization can be used. In the host Linux system, the system can access devices (such as accelerator devices) based on files. In this example, the mapping file for a dedicated accelerator (such as an FPGA device) in the system could be / dev / acla10_ref0. To access dedicated accelerators such as FPGAs that perform physical layer or partial physical layer functions within containers that handle 4G LTE and 5G NR higher-layer protocol functions, the device file can be mounted into the corresponding container. For example, a mobile phone can create a container image using Docker's Dockerfile, so that each instance based on that container image will have the mounted dedicated accelerator resources. Simultaneously, the mounted container needs to have the corresponding target driver software installed.

[0112] If a mobile phone needs to accelerate multiple communication services of different standards, and if the phone detects that there are multiple dedicated accelerators and none of them support the SRIOV method, then it determines that the first target accelerator includes at least one second accelerator (i.e., a dedicated accelerator that does not support the SRIOV method), and determines that the acceleration strategy of the first target accelerator is the second strategy (i.e., pass-through virtualization). The second strategy is used to instruct the second accelerator to create at least one container for at least one sub-service in the first target service; bind the container containing the target function of at least one sub-service to at least one second accelerator, and install the target driver software for the container containing the target function.

[0113] For example, a mobile phone has three dedicated accelerators: dedicated accelerator A, dedicated accelerator B, and dedicated accelerator C. If the phone detects that none of the three dedicated accelerators support the SRIOV method, it can be determined that the first target accelerator includes multiple (two or more) second accelerators. Assuming the dedicated accelerators are used to handle high real-time functions, Figure 6 The diagram illustrates the configuration of the second strategy. A dedicated accelerator is used to accelerate certain physical layer functions in the 4G LTE communication standard and to accelerate the processing of physical layer functions in the 5G NR communication standard. The mobile phone can create a corresponding container for each layer of the 4G communication standard service in its general-purpose processor; that is, there are seven containers for the 4G communication standard service. The container corresponding to the physical layer is denoted as the LTE container. This LTE container is bound to dedicated accelerator A. When the 4G LTE physical layer needs to use data processed by the dedicated accelerator, the LTE container can call the corresponding dedicated accelerator A to obtain the processed data. The container corresponding to the 4G LTE physical layer then calls the CPU to process other functions of that physical layer.

[0114] The mobile phone can create corresponding containers for each protocol layer in the 5G NR communication standard service, excluding the physical layer, within its general-purpose processor. Specifically, the 5G NR communication standard service has six containers: MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer. Inter-layer communication can transmit data via PIC (Inter-Process Communication). The container corresponding to the physical layer is denoted as the NR container. This NR container is bound to dedicated accelerators B and C. When the MAC layer in 5G NR needs to obtain data from the physical layer, the NR container can call the corresponding dedicated accelerators B and C to obtain the physical layer data processed by them. Alternatively, when the MAC layer in 5G NR needs to transmit data to the physical layer, it sends the data to dedicated accelerators B and C, which then communicate with the physical layers of other devices.

[0115] In this example, passthrough virtualization is used (i.e., directly binding containers to dedicated accelerators). Based on the number of dedicated accelerators and the current hardware acceleration requirements, a corresponding dedicated accelerator can be assigned to each container to accelerate the target function.

[0116] It should be noted that the mobile phone determines the current hardware acceleration requirements based on the real-time needs of the communication service. For example, the mobile phone determines that the hardware acceleration requirements include: accelerating the functions of the lower physical layer, the higher physical layer, and the lower media access layer.

[0117] Step 304: Containers accelerate some physical layer and higher-level protocols.

[0118] Specifically, some physical layer functions are implemented by the first accelerator, while the remaining functions of the physical layer in 4G LTE, as well as the functions of other protocol layers (such as the MAC layer), are implemented by a general-purpose processor. That is, the container in the general-purpose processor can call the functions of the CPU processor's higher-level protocols and some physical layer functions.

[0119] Step 305: The first electronic device determines whether a coprocessor type exists. If it does, the target accelerator is determined to include both a coprocessor and a general-purpose processor, and step 306 is executed. If it does not, the target accelerator is determined to include a general-purpose processor, and step 308 is executed.

[0120] Step 306: Coprocessor accelerates the physical layer, adaptive virtualization.

[0121] For example, the physical layer in 4G LTE and the physical layer in 5G NR are accelerated by a coprocessor. Since the computational speed of the coprocessor is slower than that of a dedicated accelerator, the processing power of the coprocessor may be less than the current hardware acceleration requirements. The mobile phone can determine a matching acceleration strategy (i.e., a first acceleration strategy) based on the current hardware acceleration requirements and the acceleration capability of the coprocessor to achieve adaptive virtualization. In this application, the following will be combined with... Figures 7-10 The process of virtualization coprocessor will not be detailed here.

[0122] Step 307: Implement high-level protocols in containers.

[0123] For example, the coprocessor accelerates the physical layer processing in a 4G LTE communication service, while other higher-level protocol layers in the 4G LTE communication service can be accelerated by a general-purpose processor. Specifically, the general-purpose processor creates containers for other higher-level protocol layers in the 4G LTE communication service, and these containers can call the general-purpose processor to accelerate the processing of those higher-level protocol layers.

[0124] Step 308: The general-purpose processor performs accelerated processing to implement a full-stack protocol stack.

[0125] For example, if the first electronic device detects the absence of a dedicated accelerator and a coprocessor, a general-purpose processor can be used to accelerate 4G LTE and 5G NR communication services. For instance, the mobile phone can create corresponding containers for each protocol layer in the 4G LTE communication service within the general-purpose processor, and these containers can call the general-purpose processor to process the functions requiring acceleration.

[0126] The following is combined with Figures 7-10 This section details the process by which the coprocessor accelerates target functions in 4G LTE and 5G NR communication services.

[0127] Figure 7 A flowchart illustrating the acceleration capabilities and hardware acceleration requirements based on coprocessors, for example, shows the acceleration of a target function, including:

[0128] Step 701: The first electronic device obtains hardware acceleration requirements.

[0129] For example, taking a mobile phone as an example, the mobile phone can use the computing power required for the target function as the current hardware acceleration requirement of the mobile phone. Optionally, the target function can be a protocol layer function predetermined by the mobile phone. For example, the target function includes the lower physical layer, higher physical layer, and lower media access layer that need to be accelerated in 4G LTE communication services. The mobile phone uses the computing power (such as the number of data processed per second) required for the lower physical layer, higher physical layer, and lower media access layer that need to be accelerated in 4G LTE communication services as the current hardware acceleration requirement of the mobile phone.

[0130] Optionally, the target function can also be each function in the sub-service. For example, the target function includes each protocol layer of 5G NR, that is, the target function includes the physical layer, MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer and NAS layer. The mobile phone can obtain the computing power required for each layer (i.e. the amount of data to be processed per second) as the hardware acceleration requirements of the current mobile phone.

[0131] Step 702: The first electronic device determines whether the acceleration capability of the coprocessor meets the hardware acceleration requirements. If it is determined that the acceleration capability of the coprocessor meets the hardware acceleration requirements, then proceed to step 703; if it is determined that the acceleration capability of the coprocessor does not meet the hardware acceleration requirements, then proceed to step 705.

[0132] For example, the mobile phone can obtain the acceleration capability of the coprocessor, which is the processing capability of the coprocessor in Table 1. The processing capability of the coprocessor can be quantified by the computing power of the coprocessor. Therefore, the mobile phone can obtain the computing power of the coprocessor and compare the computing power of the coprocessor with the hardware acceleration requirements of the mobile phone.

[0133] When a mobile phone's hardware acceleration requirements include multiple target functions, the phone can compare the computing power of the coprocessor with the computing power required for each target function in the hardware acceleration requirements. If it is detected that the computing power required for a target function is less than the processing power of the coprocessor, it is determined to execute step 703; if it is detected that the processing power of the coprocessor is less than or equal to the computing power required for each target function, it is determined to execute step 705.

[0134] For example, the current hardware acceleration requirements of a mobile phone include the computing power required for the lower physical layer, higher physical layer, and lower media access layer of 4G LTE communication services. The computing power of the coprocessor is compared with the computing power required for each of these layers. If the coprocessor's computing power is greater than any one of the required computing power for each layer, then the coprocessor's acceleration capability meets the hardware acceleration requirements. If the coprocessor's computing power is less than or equal to the computing power required for each target function, then the coprocessor's acceleration capability does not meet the hardware acceleration requirements.

[0135] If the computing power of the coprocessor is greater than the computing power of any target function, indicating that the computing power of the phone's coprocessor can accelerate a certain target function, then step 703 is executed; if the computing power of the phone's coprocessor is less than or equal to the hardware acceleration requirement, then step 705 is executed, that is, the pass-through virtualization method is used to directly bind the coprocessor to the container where a certain target function is located.

[0136] Step 703: The first electronic device is virtualized based on the coprocessor's virtualization capabilities.

[0137] For example, the mobile phone can obtain the virtualization capabilities of the coprocessor, namely the version and manufacturer information of the coprocessor. Different manufacturers or versions of coprocessors support different virtualization methods and have different degrees of virtualization. The mobile phone can accelerate the target function based on the virtualization capabilities of the coprocessor. Other communication functions are displayed in the general-purpose processor, which can be referred to in the relevant description in step 307, and will not be repeated here.

[0138] The following section uses the GPU as an example to explain the coprocessor virtualization process.

[0139] Figure 8 An example is shown of a process for virtualizing a GPU.

[0140] Step 801: The first electronic device detects whether the GPU is a Grid GPU. If it is not detected, proceed to step 802; if it is, proceed to step 806.

[0141] Specifically, the GPU manufactured by vendor Y is named "Grid". The first electronic device obtains the name of the current GPU. If the name of the current GPU is detected as "Grid", the first electronic device determines that the detected GPU is a Grid GPU. A fifth strategy can be adopted, which is the virtualization strategy specified by vendor Y. In this example, the virtualization method supported by vendor Y is: integrating the corresponding GPU toolkit into the Docker engine and adding the GPU toolkit to the container, thereby enabling the coprocessor to be virtualized into multiple virtual coprocessors (i.e., steps 806 and 807). It is understood that the virtualization methods of coprocessors from different vendors can be the same or different. This application does not limit the coprocessor virtualization method to steps 806 and 807.

[0142] When the first electronic device detects that the GPU does not belong to the Grid GPU, it executes step 802 to detect whether the current GPU is a GVT GPU.

[0143] Step 802: The first electronic device detects whether the GPU is a GVT GPU; if it is not detected, proceed to step 803; if it is, proceed to step 806.

[0144] For example, the GPU manufactured by vendor I is named "GVT". After obtaining the name of the current GPU, the first electronic device checks whether the name is "GVT". If it is, it determines that the current GPU is a GVT GPU; the fifth strategy can be used. If the first electronic device detects that the current GPU is not a GVT GPU, it can execute step 803.

[0145] Step 803: The first electronic device detects whether it supports SRIOV virtualization. If it detects that SRIOV virtualization is not supported, proceed to step 804; if it detects that SRIOV virtualization is supported, proceed to step 805.

[0146] For example, if the first electronic device detects that the current GPU is neither a Grid GPU nor a GVT GPU, it can determine whether the GPU supports SRIOV virtualization. If the virtualization capability of the current GPU indicates that the GPU (e.g., a GPU manufactured by vendor A) supports SRIOV virtualization, then the third strategy can be adopted. This third strategy is used to instruct the first electronic device to configure the coprocessor according to SRIOV; to instruct the first electronic device to bind the container containing the target function in at least one sub-service to at least one VF in the coprocessor; and to instruct the first electronic device to install the target driver software in the container containing the target function.

[0147] After the first electronic device determines the third strategy, step 805 can be executed, that is, the first electronic device configures the first target accelerator (i.e., configures the coprocessor and general-purpose processor) according to the instructions of the third strategy to achieve the target function acceleration of the communication service.

[0148] If the first electronic device detects that the current GPU does not support SRIOV virtualization, then proceed to step 804.

[0149] Step 804: Install the GPU driver in the container using API forwarding virtualization.

[0150] For example, if the first electronic device detects that the current GPU does not belong to either the Grid GPU or the GVT GPU, and that the current GPU does not support the SRIOV method, then it can determine to adopt the fourth strategy. This fourth strategy is used to instruct the creation of at least one container in the general-purpose processor for at least one sub-service of the first target service (such as a 4G LTE communication service or a 5G NR communication service); to instruct the first electronic device to bind the container containing the target function of at least one sub-service to the coprocessor; and to instruct the first electronic device to install target driver software in the container containing the target function, creating shared memory in the host system.

[0151] Specifically, the mobile phone creates a container corresponding to the target communication service (such as 4G LTE communication service) on the general-purpose processor, such as an LTE container, and installs a proprietary driver device (software) that matches the current GPU model on the LTE container, binding the GPU to the LTE container to achieve GPU pass-through virtualization and accelerate the 4G LTE communication service.

[0152] The mobile phone allocates a block of memory in the host system for containers corresponding to the target communication service to share with containers of other communication standards. For example, the LTE container shares this shared memory with the NR container. Containers of other communication standards (such as the container corresponding to 5G NR) submit communication acceleration-related instructions through shared memory. The container of the default communication standard that exclusively uses the GPU sends instructions to the GPU, and after execution, the relevant data is transmitted back to the container of the other communication standard that sent the instructions along the original path.

[0153] Containers share data and instruction storage space, similar to traditional API redirection (where the front end sends data instructions to the back end). This reduces the latency caused by data copying and transmission to some extent, thus improving GPU virtualization performance.

[0154] For example, the phone detects that there is no dedicated accelerator in the current device and obtains the type of coprocessor. The phone determines that the acceleration capability of the coprocessor is greater than the hardware acceleration requirements of the current hardware. The phone detects that the coprocessor does not belong to either the Grid GPU or the GVT GPU; and the coprocessor does not support SRIOV virtualization. The phone then determines to adopt the fourth strategy. Following the instructions of the fourth strategy, the phone creates corresponding containers for each layer of the 4G LTE communication service protocol in the general-purpose processor. That is, the current 4G LTE communication standard includes 7 containers, and the physical layer corresponding containers (such as...) Figure 9 The LTE container shown is bound to the GPU, and a matching target driver is installed within the LTE container. A corresponding container is created in the general-purpose processor for each protocol layer of 5G NR. Shared memory is created in the host system, accessible to both the LTE and NR containers.

[0155] The LTE container can invoke the GPU to handle some physical layer functions in 4G LTE communication services; however, the NR container cannot invoke the GPU because it is occupied by the LTE container. The NR container can send a data retrieval request (referred to as request A) to the LTE container via shared memory. The LTE container retrieves the data retrieval request from the shared memory, invokes the GPU to process the physical layer data in 5G NR communication services, and sends the processed data back to the NR container via shared memory. This allows the NR container to accelerate physical layer processing through the GPU. The NR container can also transfer data (referred to as data A) to the shared memory. The LTE container retrieves data A from the shared memory and then transmits data A to the physical layer of other devices via the GPU.

[0156] In this example, the coprocessor is illustrated using a GPU. Other types of coprocessors (such as NPUs) and GPU processing types will not be listed in this example.

[0157] Step 805: Use SRIOV virtualization to bind the virtual accelerator to the container.

[0158] For example, if the mobile phone detects that the coprocessor supports SRIOV virtualization, it determines that a third strategy can be adopted. The third strategy is used to instruct the mobile phone to configure the coprocessor in SRIOV mode; instruct the mobile phone to create at least one container in the general processor for at least one sub-service of the first target service; instruct the mobile phone to bind the container where the target function of at least one sub-service is located to at least one VF in the coprocessor; and instruct the mobile phone to install the target driver software for the container where the target function is located.

[0159] For example, you can refer to Figure 10As shown; assume the coprocessor is used to accelerate some physical layer functions in the 4G LTE communication standard and to accelerate the processing of physical layer functions in the 5G NR communication standard. The mobile phone can create a corresponding container for each layer of the 4G communication standard service in the general-purpose processor; that is, there are 7 containers for the 4G communication standard service. The container corresponding to the physical layer is denoted as the LTE container, and this LTE container is bound to a VF in the dedicated accelerator (e.g., ...). Figure 10 As shown, when the 4G LTE physical layer needs to use data processed by the coprocessor, the LTE container can call the corresponding VF to obtain the data processed by the coprocessor. Other functions in the physical layer of this 4G LTE are implemented in the general-purpose processor.

[0160] The mobile phone can create corresponding containers for each protocol layer (excluding the physical layer) in the general-purpose processor for 5G NR communication services. Specifically, there are six containers for 5G NR communication services: MAC layer, RLC layer, PDCP layer, SDAP layer, RRC layer, and NAS layer. Inter-layer communication can transmit data via PIC (Inter-Process Communication). The container corresponding to the physical layer is denoted as the NR container, and this NR container is bound to a VF (Vehicle Function) in a dedicated accelerator (e.g., ...). Figure 10 As shown, when the MAC layer in 5G NR needs to obtain data from the physical layer, the NR container can call the corresponding VF to obtain the physical layer data processed by the coprocessor. Alternatively, when the MAC layer in 5G NR needs to transmit data to the physical layer, it sends the data to the coprocessor through the VF, and the coprocessor obtains the data transmitted by the MAC layer and communicates with the physical layers of other devices.

[0161] Specifically, the target driver software for calling the corresponding VF is installed in the NR container, while the target driver software for the 5G NR container does not need to be installed in the containers corresponding to other layers.

[0162] Optionally, the NR container can also correspond to multiple VFs. For example, three VFs are created in the dedicated accelerator and labeled as VF-21, VF-22, and VF-23, respectively. Among them, the LTE container is bound to VF-21, and the NR container is bound to VF-22 and VF-23.

[0163] Alternatively, the mobile phone can also create a container for each communication standard, meaning that the seven layers in the 5G NR communication service share a single container.

[0164] Step 806: Integrate the GPU toolkit into the Docker engine.

[0165] Step 807: Add the GPU device to the container.

[0166] Steps 806 and 807 are virtualization methods defined by the vendor, and will not be described in detail here.

[0167] The above Figure 7 and Figure 8 This section details the process by which the coprocessor accelerates the target functions of various communication standards within a communication service.

[0168] Step 704: The coprocessor of the first electronic device implements some communication functions, and the container implements other communication functions.

[0169] For example, containers in a general-purpose processor can implement other functions in communication services. For instance, containers for other higher-level protocol layers in 4G LTE communication services can be created in the general-purpose processor. These higher-level protocol layer containers can call the general-purpose processor to accelerate the processing of the higher-level protocol layers.

[0170] Step 705: Pass through virtualization and directly bind to the container.

[0171] For example, since the acceleration capability of the coprocessor is less than or equal to the hardware acceleration requirements of the current device, the mobile phone can bind the coprocessor to a specified container to accelerate a specific target function. For instance, if the mobile phone can specify acceleration of certain physical layer functions in 4G LTE communication services, it can directly bind the container corresponding to the physical layer to the coprocessor, allowing the container to call the coprocessor to process those physical layer functions. Similarly, other communication functions can be implemented by a general-purpose processor. For example, containers corresponding to other protocol layers can be created in the general-purpose processor, or virtual machine technology can be used in the general-purpose processor to implement the functions of other protocol layers.

[0172] When an electronic device determines that the target accelerator includes both coprocessors and general-purpose processors, it can determine an acceleration strategy that matches the electronic device based on the virtualization capabilities of the coprocessor. This allows for reasonable virtualization configuration of the coprocessor based on its virtualization capabilities, flexibly accelerating the target function and increasing the application scenarios for coprocessor acceleration.

[0173] In this example, the electronic device can adaptively adopt different virtualization strategies based on the type and virtualization capabilities of the target accelerator to accelerate communication services of at least one communication standard. This maximizes the utilization of the electronic device's hardware capabilities and reduces its cost. Furthermore, directly calling the hardware through containers is fast and suitable for communication services with high real-time requirements of the accelerator.

[0174] In some embodiments, due to different acceleration strategies, the container needs to install matching target driver software. The first electronic device stores installation packages for multiple target driver software locally, occupying storage space and making it inconvenient to update the target driver software. In this example, the first electronic device can request to download the target driver software from the server and obtain the currently required target driver software from the server. The specific process can be referred to... Figure 11 ,include:

[0175] Step 1001: The mobile terminal sends a request to the server to download the target driver software.

[0176] For example, the mobile terminal can determine a first acceleration strategy based on the current first hardware information. In this example, the mobile terminal is equivalent to the first electronic device in other embodiments. The process of obtaining the first hardware information in this example can be referred to... Figure 3 The relevant description of the first electronic device acquiring the first hardware information will not be repeated here.

[0177] The mobile terminal can determine a first target accelerator based on the first hardware information, and determine a first acceleration strategy that matches the first target accelerator. The mobile terminal can then generate a request to download the target driver software based on the identification information of the first acceleration strategy, and send the request to the server.

[0178] For example, the mobile phone obtains current hardware information and detects the presence of a dedicated accelerator that supports SRIOV virtualization. The mobile phone determines to adopt the first policy and obtains the identification information of the first policy (e.g., denoted as policy-1). The mobile phone generates a download request containing the identification information of the first policy and sends the download request to the server to request the installation package of policy-1.

[0179] If the phone detects that there is no dedicated accelerator supporting SRIOV virtualization, and the number of detected dedicated accelerators is greater than 1, then it determines that the second strategy can be adopted, and obtains the identification information of the second strategy (e.g., denoted as policy-2). The phone generates a download request containing the identification information of the second strategy and sends the download request to the server to request the installation package of policy-2.

[0180] If the phone detects the absence of a dedicated accelerator but the presence of a coprocessor, and the phone determines that the coprocessor's acceleration capabilities meet the hardware acceleration requirements, it obtains the coprocessor's virtualization information. If the phone detects that the coprocessor (such as a GPU) belongs to a Grid GPU or GVT GPU, it determines to adopt the fifth policy and obtains the identification information of the fifth policy (e.g., denoted as policy-5). The phone generates a download request containing the identification information of the fifth policy and sends the download request to the server to request the installation package of policy-5.

[0181] If the phone detects that the coprocessor does not belong to either the Grid GPU or the GVT GPU, and supports SRIOV virtualization, it determines to adopt the third policy and obtains the identification information of the third policy (e.g., denoted as policy-3). The phone generates a download request containing the identification information of the fifth policy and sends the download request to the server to request the installation package of policy-3.

[0182] If the phone detects that the coprocessor does not belong to either the Grid GPU or the GVT GPU, and does not support SRIOV virtualization, it determines to adopt the fourth policy and obtains the identification information of the fourth policy (e.g., denoted as policy-4). The phone generates a download request containing the identification information of the fourth policy and sends the download request to the server to request the installation package of policy-4.

[0183] Optionally, the download request may include identification information of the target driver software in the acceleration strategy.

[0184] Step 1002: The server queries the target driver software.

[0185] For example, the server can query the latest version of the target driver software based on the information in the received request. For instance, if the request received by the server includes the identification information of a first policy, the server queries the installation package of the driver software under the first policy and obtains the query result. Optionally, the server can also query the installation package of the target driver software based on the identification information of the target driver software, and the server will then return the query result to the mobile terminal.

[0186] Step 1003: The server sends the query results back to the mobile terminal.

[0187] For example, the query result is used to indicate whether the installation package of the target driver software exists on the server. If the query result indicates that the installation package of the target driver software exists on the server, the query result may also include the download address of the target driver software installation package. Optionally, the query result may also include information such as the version information and installation package size of the retrieved target driver software.

[0188] Step 1004: The mobile terminal downloads the target driver software from the server.

[0189] For example, the mobile terminal receives a query result. If the query result indicates that the target driver software exists on the server, it can obtain the download address of the target driver software installation package from the query result. The mobile terminal then downloads the target driver software installation package from the server according to the download address.

[0190] Step 1005: Install the target driver software on the mobile terminal.

[0191] For example, the mobile terminal determines the installation location of the target driver software based on a determined acceleration strategy. The mobile terminal then installs the target driver software at the determined installation location.

[0192] Step 1006: The mobile terminal sends loading information back to the server.

[0193] For example, if a mobile terminal successfully downloads and installs the target driver software, it can send a message to the server indicating that the loading is complete. If the mobile terminal fails to install the target driver software, it can send a message to the server indicating that the loading failed. This message can include the reason for the download failure or the reason for the installation failure. The server can store this information to improve the installation package. For instance, the server can periodically collect data on installation failures due to the same reason, allowing it to update the installation package and reduce the number of installation failures caused by this reason.

[0194] In this example, the server can update the target driver software installation package in a timely manner based on the loading information returned by the server, reducing the number of installation failures. At the same time, storing the target driver software installation package on the server side also facilitates timely updates, reducing the storage space occupied on the mobile terminal.

[0195] In some embodiments, if the mobile terminal (or the first electronic device) malfunctions, the mobile terminal can redetermine the target accelerometer and reconfigure the accelerometer. The specific process is as follows: Figure 12 As shown, it includes:

[0196] Step 1101: The mobile terminal detects whether there is a faulty accelerator in the first target accelerator. If the first electronic device detects that there is a fault in the first target accelerator, then proceed to step 1102; if the first electronic device does not detect a fault in the first target accelerator, then end the process of reconfiguring the accelerator.

[0197] For example, the mobile terminal can periodically generate hardware detection commands, with the period lasting for one month, six months, one year, or more than two years. In response to the hardware detection commands, the mobile terminal obtains the status information of each accelerator, including whether the accelerator has experienced a hardware failure.

[0198] Optionally, the status information of the accelerator may also include information on whether the processing power of the accelerator meets the hardware acceleration requirements.

[0199] For example, the mobile terminal detects whether the first target accelerator is faulty based on the accelerator's status information. For instance, taking a mobile phone as an example, the first target accelerator includes a general-purpose processor and a dedicated accelerator A. The mobile phone obtains the accelerator's status information, which includes information about a faulty dedicated accelerator A, a normal general-purpose processor, and a normal dedicated accelerator B. Based on the accelerator's status information, the mobile phone determines that a faulty dedicated accelerator exists within the first target accelerator, and then proceeds to step 1102.

[0200] If the mobile terminal detects that the first target accelerator is not faulty, the process of reconfiguring the accelerator can be terminated.

[0201] Step 1102: The mobile terminal re-determines the target accelerator and current hardware acceleration requirements.

[0202] For example, the mobile terminal can reacquire the hardware information of the accelerator in the current terminal to redetermine a new target accelerator (i.e., a second target accelerator). The process of the mobile terminal redetermining the target accelerator can be referred to... Figures 3-8 The relevant descriptions will not be repeated here.

[0203] Mobile terminals can redetermine hardware acceleration requirements based on the processing capabilities of a new target accelerator. For example, a mobile phone has a dedicated accelerator A and a coprocessor G. One communication standard requires acceleration at the lower physical layer, higher physical layer, and lower media access layer, with the dedicated accelerator A performing hardware acceleration. When the dedicated accelerator A fails, the mobile phone can accelerate via the coprocessor. When the coprocessor's processing capabilities cannot meet the original hardware acceleration requirements, the mobile phone can obtain the acceleration requirements for each protocol layer under that communication standard. When the mobile phone detects that the coprocessor's processing capabilities meet the acceleration requirements of at least one protocol layer, it can redetermine the current hardware acceleration requirements, such as the new acceleration requirements being the lower physical layer, or both the lower and higher physical layers.

[0204] Step 1103: The mobile terminal implements communication functions based on the target accelerator and hardware acceleration requirements.

[0205] For example, the mobile terminal can configure the target accelerator according to the determined target accelerator and the redefined hardware acceleration requirements to realize the communication function, which can be referred to as... Figures 3 to 10 The relevant descriptions in the text will not be repeated here.

[0206] In some embodiments, if the hardware acceleration requirements of the mobile terminal change or the hardware information of the mobile terminal changes (e.g., the accelerator is replaced), the hardware acceleration requirements can be redefined based on the processing capability of the accelerator in the mobile terminal, and the communication function can be implemented. This process is as follows: Figure 13 As shown, it includes:

[0207] Step 1201: The mobile terminal checks whether the hardware capabilities of the target accelerator meet the hardware acceleration requirements. If yes, the process ends. If not, proceed to step 1202.

[0208] For example, this step is similar to step 1101, and the relevant description of step 1101 can be referred to.

[0209] Optionally, the mobile terminal can also generate a hardware detection command after the hardware has been replaced. Alternatively, the user can input the hardware detection command after the user has replaced the hardware.

[0210] In response to a hardware detection command, the mobile terminal obtains the current status information of each accelerator. The status information of each accelerator includes whether its processing power meets the hardware acceleration requirements.

[0211] The mobile terminal can obtain the status information of the target accelerator. If it detects that the processing power of the target accelerator does not meet the hardware acceleration requirements, it will check whether the processing power of other accelerators meets the hardware acceleration requirements. If the mobile terminal detects that there is an accelerator whose processing power does not meet the hardware acceleration requirements, it can re-determine a new target accelerator, i.e., execute step 1202. If the mobile terminal detects that the processing power of the current target accelerator meets the current hardware acceleration requirements, the process ends.

[0212] Understandably, if no accelerator meets the current hardware acceleration requirements, then the hardware acceleration requirements can be redefined.

[0213] Step 1202: The mobile terminal re-determines the target accelerator and current hardware acceleration requirements.

[0214] For example, this step is similar to step 1102. The mobile terminal can obtain the processing power of each accelerator and can select the accelerator that meets the current hardware acceleration requirements as the new target accelerator. The mobile terminal can then proceed according to... Figures 3-8 The acceleration strategy determined in the code will be configured, which will not be elaborated here.

[0215] If the mobile terminal detects that there is no accelerator that meets the current hardware acceleration requirements, the mobile terminal will adjust the hardware acceleration requirements. The adjustment process can be referred to the description in step 1102.

[0216] Mobile terminals can redetermine their hardware acceleration requirements based on the processing capabilities of a new target accelerator. For example, a mobile phone has a dedicated accelerator A and a coprocessor G. One communication standard requires acceleration at the lower physical layer, higher physical layer, and lower media access layer, with dedicated accelerator A performing hardware acceleration. If the processing capability of dedicated accelerator A in the phone does not meet the hardware acceleration requirements, the phone checks if there is an accelerator that meets the current hardware acceleration requirements. If not, the phone can redetermine its current hardware acceleration requirements, such as lowering the requirements to the lower physical layer and higher physical layer.

[0217] Step 1203: The first electronic device implements communication functions based on the target accelerator and hardware acceleration requirements.

[0218] For example, this step is largely the same as step 1103, and can be referred to the relevant description in step 1103, which will not be repeated here.

[0219] In this example, the phone can promptly update to target accelerators that meet the current hardware acceleration requirements, enabling other accelerators to perform acceleration backup functions. Simultaneously, if no accelerator meets the current hardware acceleration requirements, the phone can adjust these requirements in a timely manner to avoid the inability to achieve acceleration capabilities due to the lack of a suitable accelerator.

[0220] In some embodiments, the mobile terminal can obtain current hardware information and upload it to the server. The server then determines an acceleration strategy based on the mobile terminal's hardware information. The server sends the acceleration strategy to the mobile terminal, which can configure a target accelerator according to the determined acceleration strategy to accelerate at least one sub-service of the target service. The interaction between the mobile terminal and the server is as follows: Figure 14 As shown, it includes:

[0221] Step 1301: The mobile terminal sends a function loading request to the server.

[0222] For example, the mobile terminal can obtain current hardware information. The process of obtaining hardware information can refer to step 201, and will not be repeated here. The function loading request may include: the mobile terminal's hardware information, the first target service, and information on the types of virtualization currently supported by the mobile terminal. The types of virtualization currently supported by the mobile terminal may include: information on CPU virtualization, coprocessor virtualization, and dedicated accelerator virtualization supported by the mobile terminal.

[0223] Step 1302: The server determines the list of features based on the feature loading request.

[0224] For example, upon receiving a feature loading request, the server obtains the mobile terminal's hardware information, a first target service, and information on the virtualization types currently supported by the mobile terminal. Based on the hardware information, the server determines a first target accelerator matching the first target service and a first acceleration strategy matching the first target accelerator. This first acceleration strategy is used to instruct the mobile terminal to configure the first target accelerator and the target driver software.

[0225] Optionally, the server can also prioritize excluding accelerators that cannot be virtualized based on information about the types of virtualization currently supported by the mobile terminal, which can shorten the speed of determining the first target accelerator and the speed of matching the first acceleration strategy.

[0226] For example, a mobile terminal includes a dedicated accelerator A, a dedicated accelerator B, a coprocessor G, and a general-purpose processor. The primary target service is a communication service, which requires acceleration of both 4G LTE and 5G NR communication services. The server obtains information about the virtualization types supported by the current mobile terminal and determines that accelerator A, coprocessor G, and the general-purpose processor all support virtualization. The server then determines the first accelerator from among the accelerators that support virtualization, without needing to determine the first accelerator from among the dedicated accelerators based on hardware information.

[0227] The server-determined list of functions includes a first target accelerator and a matching first acceleration strategy. The process by which the server determines the first target accelerator and the first acceleration strategy includes:

[0228] Step 1401: The server determines the first target accelerator that matches the first target service based on the first hardware information.

[0229] In some embodiments, the server detects whether a dedicated accelerator type accelerator exists in the current device. If the server detects that the mobile terminal has a dedicated accelerator type accelerator, it determines that the first target accelerator includes a dedicated accelerator and a general-purpose processor. If the server detects that the mobile terminal does not have a dedicated accelerator type accelerator, it detects whether a coprocessor type accelerator exists in the current mobile terminal. If the server detects that the mobile terminal has a coprocessor type accelerator, it determines that the first target accelerator includes a coprocessor and a general-purpose processor. If the server detects that the mobile terminal does not have a coprocessor type accelerator, it determines that the first target accelerator includes a general-purpose processor.

[0230] In this application, the first target service is taken as an example of the communication service of a mobile terminal, and the process of the server determining the first target accelerator is described in detail.

[0231] Specifically, based on the first hardware information, the server determines whether a dedicated accelerator type accelerator exists in the mobile terminal. If the server determines that the mobile terminal has a dedicated accelerator type accelerator, then the first target accelerator is determined to include both a dedicated accelerator and a general-purpose processor.

[0232] If the server determines that no dedicated accelerator type accelerator exists, it then determines whether the mobile terminal has a coprocessor type accelerator. If a coprocessor type accelerator exists in the mobile terminal, the target accelerator includes both a coprocessor and a general-purpose processor. If no coprocessor type accelerator exists in the mobile terminal, the target accelerator includes only a general-purpose processor.

[0233] Step 1402: The server obtains the first acceleration strategy that matches the first target accelerator.

[0234] In this example, virtualization technology can be used to enable different services to share the first target accelerator. The server can determine a matching first acceleration strategy based on the virtualization capabilities of the first target accelerator. The first acceleration strategy is used to instruct the first electronic device how to configure the first target accelerator.

[0235] In some embodiments, if the server determines that the first target accelerator includes a dedicated accelerator and a general-purpose processor, the server may detect whether there is a dedicated accelerator that supports the SRIOV method. If it detects that there is, the server determines to adopt the first strategy. If it detects that there is no dedicated accelerator that supports the SRIOV method, the server determines to adopt the second strategy.

[0236] The first strategy is used to instruct the mobile phone to configure the first accelerator in the manner of SRIOV; to instruct the mobile phone to create at least one container in the second accelerator for at least one sub-service of the first target service; to instruct the mobile phone to bind the container where the target function of at least one sub-service is located to at least one virtual function (VF) in the first accelerator; and to instruct the mobile phone to install the target driver software in the container where the target function is located.

[0237] The second strategy is used to instruct the creation of at least one container in the second accelerator for at least one sub-service of the first target service; to bind the container containing the target function of at least one sub-service to at least one first accelerator, and to install the target driver software in the container containing the target function.

[0238] In some embodiments, if the server determines that the first target accelerator includes a coprocessor and a general-purpose processor, it determines whether the acceleration capability of the coprocessor meets the hardware acceleration requirements. If the server determines that the acceleration capability of the coprocessor meets the hardware acceleration requirements, it can determine an acceleration strategy based on the virtualization information of the coprocessor. If the server determines that the acceleration capability of the coprocessor does not meet the hardware acceleration requirements, it determines to adopt a pass-through virtualization strategy. The pass-through virtualization strategy is used to instruct the mobile terminal to create a container for the target function in the general-purpose processor, directly bind the container for the target function to the coprocessor, and install the corresponding target driver software on the container for the target function.

[0239] In this example, the coprocessor is a GPU. The server can detect whether the GPU is a Grid GPU or a GVT GPU. If the server detects that the GPU is a Grid GPU or a GVT GPU, it will determine to use the fifth strategy.

[0240] If the server detects that the GPU is neither a Grid GPU nor a GVT GPU, it checks whether the GPU supports SRIOV virtualization. If it does, the server uses the third strategy. If it does not support SRIOV virtualization, the server uses the fourth strategy.

[0241] For a description of how the server determines the strategy, please refer to the process of determining the acceleration strategy locally on the mobile terminal (e.g., ...). Figures 3-8 (This will not be elaborated further here.)

[0242] Step 1303: The server sends a function loading response to the mobile terminal.

[0243] For example, the server can generate a function loading response message according to a first acceleration strategy. This function acceleration response message can include a list of functions that implement the target service. This list of functions may include: the type and version information of the accelerator in the first target accelerator, and information about the first acceleration strategy. The information about the first acceleration strategy includes the type and version information of the target driver software, and may also include the download address of the target driver software's installation package. The server then sends this function loading response message back to the mobile terminal.

[0244] Step 1304: The mobile terminal obtains the corresponding function from the server's function list and downloads the function.

[0245] For example, upon receiving a feature loading response message, the mobile terminal can obtain information about the first target accelerator from the message, thereby determining the first target accelerator. The mobile terminal can also obtain information about the first acceleration strategy and download the installation package of the target driver software for that strategy from the server.

[0246] Step 1305: Install the driver on the mobile terminal.

[0247] The mobile terminal configures the first target accelerator according to the instructions of the first acceleration strategy and installs the target driver software on the container where the target function is located. The mobile terminal configuration process can be referred to... Figure 5 , 6 The descriptions of numbers 9 and 10 will not be repeated here.

[0248] Step 1306: The mobile terminal sends function loading information back to the server.

[0249] For example, the mobile terminal can send function loading information back to the server. This function loading information is used to indicate whether the mobile terminal has completed downloading the target function and whether the first target accelerator has been successfully configured according to the first acceleration strategy.

[0250] The server can adjust the target driver software in the first acceleration strategy based on the function loading information, and can also analyze the reasons for download failures or the reasons for target driver software installation failures.

[0251] In this example, the server determines the first target accelerator and the corresponding acceleration strategy, which can reduce the computational load on the mobile terminal and avoid storing unnecessary driver software on the mobile terminal, thus occupying the local storage resources of the mobile terminal.

[0252] It is understood that, in order to achieve the above-mentioned functions, electronic devices include hardware and / or software modules that perform the respective functions. Based on the algorithmic steps of the examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0253] This embodiment also provides a computer storage medium storing computer instructions. When these computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to achieve the target service acceleration method described in the above embodiment. The storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0254] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to achieve the method for accelerating the target business described in the above embodiment.

[0255] In this embodiment, the electronic device, computer storage medium, computer program product or chip are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding method provided above, and will not be repeated here.

[0256] Any content in the various embodiments of this application, as well as any content in the same embodiment, can be freely combined. Any combination of the above content is within the scope of this application.

[0257] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for accelerating target business processes, characterized in that, Applied to a first electronic device, the method includes: Obtain first hardware information of the first electronic device, the first hardware information including: the type of each accelerator in the first electronic device and the virtualization information of each accelerator, the type of accelerator including: general processor type, dedicated accelerator type and coprocessor type, the virtualization information is used to indicate the virtualization method supported by the accelerator; Based on the first hardware information, a first target accelerator and a first acceleration strategy matching the target service are determined. The first acceleration strategy is used to instruct the first electronic device to configure the first target accelerator. According to the first acceleration strategy, the first target accelerator is configured to process at least one sub-service among the target services; Wherein, configuring the first target accelerator according to the first acceleration strategy includes: In the case where the accelerator type in the first target accelerator includes a coprocessor type and a general-purpose processor type, and the first target accelerator of the coprocessor type supports the SRIOV method, at least one container is created in the general-purpose processor for at least one sub-service in the target service; the container where the target function in the at least one sub-service is located is bound to at least one virtual function (VF) in the coprocessor; and the target driver software is installed in the container where the target function is located. In the case where the accelerator type in the first target accelerator includes a coprocessor type and a general-purpose processor type, and the first target accelerator of the coprocessor type does not support the SRIOV method and does not belong to a preset model, at least one container is created in the general-purpose processor for at least one sub-service of the target service; the container where the target function of the at least one sub-service is located is bound to the coprocessor; the target driver software is installed in the container where the target function is located; shared memory is created in the host system, and the container where the target function is located forwards instructions to other containers through the shared memory so that other containers can call the coprocessor.

2. The method according to claim 1, characterized in that, Based on the first hardware information, a first target accelerator and a first acceleration strategy matching the target service are determined, including: Based on the type of each accelerator, determine the type of accelerator in the first target accelerator; Based on the type of accelerator and virtualization information in the first target accelerator, the first target accelerator and the first acceleration strategy are determined.

3. The method according to claim 2, characterized in that, Based on the type of each accelerator, determine the type of accelerator in the first target accelerator, including: Based on the type of each accelerator, detect whether the accelerator of the first electronic device has a dedicated accelerator type; If a dedicated accelerator type is detected, it is determined that the accelerator types in the first target accelerator include dedicated accelerator types and general-purpose processor types; If no dedicated accelerator type is detected, then the presence of a coprocessor type in the accelerator of the first electronic device is detected. If a coprocessor type is detected, then the accelerator type in the first target accelerator is determined to include the coprocessor type and the general processor type; If no dedicated accelerator type and no coprocessor type are detected, then it is determined that the accelerator type in the first target accelerator includes the general-purpose processor type.

4. The method according to claim 3, characterized in that, Based on the type of accelerator and virtualization information in the first target accelerator, the first target accelerator and the first acceleration strategy are determined, including: If the accelerator type in the first target accelerator includes dedicated accelerator type and general processor type, then obtain the virtualization information of each dedicated accelerator; Based on the virtualization information of each dedicated accelerator, detect whether there is a dedicated accelerator that supports the single root virtualization SRIOV method; If a dedicated accelerator supporting the SRIOV method is detected, the first target accelerator is determined to include a first accelerator and a general-purpose processor, and the first acceleration strategy is determined to include a first strategy, wherein the first accelerator is a dedicated accelerator supporting the SRIOV method. If it is detected that there is no dedicated accelerator that supports the SRIOV method and the number of dedicated accelerators is greater than or equal to 1, then it is determined that the first target accelerator includes at least one second accelerator, and the first acceleration strategy includes a second strategy, wherein the second accelerator is a dedicated accelerator that does not support the SRIOV method.

5. The method according to claim 4, characterized in that, The step of configuring the first target accelerator according to the first acceleration strategy includes: If the first acceleration strategy includes the first strategy, then the first accelerator is configured according to the SRIOV method; The general-purpose processor creates at least one container for at least one sub-service in the first target service; binds the container containing the target function in the at least one sub-service to at least one virtual function (VF) in the first accelerator; and installs target driver software on the container containing the target function. If the first acceleration strategy includes the second strategy, at least one container is created in the general-purpose processor for at least one sub-service in the first target service; the container containing the target function in the at least one sub-service is bound to at least one of the second accelerators; and the target driver software is installed in the container containing the target function.

6. The method according to claim 3, characterized in that, The step of determining the first target accelerator and the first acceleration strategy based on the type of accelerator and virtualization information in the first target accelerator includes: If the accelerator type in the first target accelerator includes the coprocessor type and the general processor type, then the acceleration capability of the coprocessor is obtained. Obtain the current hardware acceleration requirements, which include: the computing power of the hardware required for the target function; If it is determined that the acceleration capability meets the hardware acceleration requirements, then the first acceleration strategy is determined based on the virtualization information of the coprocessor. If it is determined that the acceleration capability does not meet the hardware acceleration requirements, then the first acceleration strategy is determined to include a pass-through virtualization strategy.

7. The method according to claim 6, characterized in that, Determining the first acceleration strategy based on the virtualization information of the coprocessor includes: If the coprocessor is detected to belong to the preset model, then the first acceleration strategy is determined to include the fifth strategy.

8. The method according to claim 5 or 7, characterized in that, If the target service is a target communication service, the target communication service includes at least one type of communication service; Creating at least one container in the general-purpose processor for at least one sub-service of the first target service includes: Allocate a corresponding container for each type of communication service; or, Allocate a corresponding container for each protocol layer of each type of communication service; or, Assign a corresponding container to each preset protocol layer of each communication service standard, and assign a shared container to protocol layers other than the preset protocol layers.

9. The method according to claim 5 or 7, characterized in that, The target functions include: physical layer functions, and / or, media access layer functions.

10. The method according to claim 1, characterized in that, The method further includes: If a fault is detected in the first target accelerator or if the acceleration capability of the first target accelerator does not meet the current hardware acceleration requirements, the step of obtaining the first hardware information of the first electronic device is re-executed.

11. The method according to claim 5 or 7, characterized in that, Before installing the target driver software on the container where the target function resides, the method further includes: A loading request is sent to the second electronic device, which then queries the installation package of the target driver software and sends the installation package of the target driver software to the first electronic device. Receive the installation package of the target driver software.

12. A method for accelerating target business processes, characterized in that, Applied to a first electronic device, including: Obtain first hardware information of the first electronic device, the first hardware information including: the type of each accelerator in the first electronic device and the virtualization information of each accelerator, the type of accelerator including: general processor type, dedicated accelerator type and coprocessor type, the virtualization information is used to indicate the virtualization method supported by the accelerator; A first acceleration request is sent to a second electronic device, the first acceleration request including the first hardware information and the target service information; the second electronic device determines a first target accelerator and a first acceleration strategy matching the target service based on the first hardware information, the first acceleration strategy including instructions for the first electronic device to configure the first target accelerator; Obtain information about the first target accelerator and the first acceleration strategy from the second electronic device; According to the first acceleration strategy, the first target accelerator is configured to process at least one sub-service in the first target service; Wherein, configuring the first target accelerator according to the first acceleration strategy includes: If the first acceleration strategy includes the third strategy, then the coprocessor is configured according to the SRIOV method; at least one container is created in the general-purpose processor for at least one sub-service in the target service; the container containing the target function in the at least one sub-service is bound to at least one virtual function (VF) in the coprocessor; and the target driver software is installed in the container containing the target function. If the first acceleration strategy includes a fourth strategy, then at least one container is created in the general-purpose processor for the at least one sub-service; the container containing the target function in the at least one sub-service is bound to the coprocessor; the target driver software is installed in the container containing the target function; shared memory is created in the host system, and the container containing the target function forwards instructions to other containers through the shared memory.

13. The method according to claim 12, characterized in that, The step of configuring the first target accelerator according to the first acceleration strategy includes: If the first acceleration strategy includes the first strategy, then the first accelerator is configured according to the single root virtualization SRIOV method, and the first accelerator is a dedicated accelerator that supports SRIOV; at least one container is created in the general-purpose processor for at least one sub-service in the target service; the container where the target function in the at least one sub-service is located is bound to at least one virtual function (VF) in the first accelerator; and the target driver software is installed in the container where the target function is located. If the first acceleration strategy includes a second strategy, at least one container is created in the general-purpose processor for at least one sub-service in the target service; the container containing the target function in the at least one sub-service is bound to at least one second accelerator, wherein the second accelerator is a dedicated accelerator that does not support the SRIOV method; and the target driver software is installed in the container containing the target function. If the first acceleration strategy includes a fifth strategy, then a toolkit for the target function is added to the coprocessor.

14. The method according to claim 12 or 13, characterized in that, The method further includes: When a fault is detected in the first target accelerator or when the acceleration capability of the first target accelerator does not meet the current hardware acceleration requirements, the first hardware information of the first electronic device is reacquired. A second acceleration request is sent to the second electronic device. The second acceleration request includes: information about the target service and new first hardware information. The second electronic device determines a second target accelerator and a second acceleration strategy that match the target service based on the new first hardware information. The second acceleration strategy includes instructions for the first electronic device to configure the second target accelerator. Obtain information about the second target accelerator and the corresponding second acceleration strategy from the second electronic device; According to the second acceleration strategy, the second target accelerator is configured to process at least one sub-service among the target services.

15. A method for accelerating target business processes, characterized in that, Applied to a second electronic device, including: The system receives a first acceleration request sent by a first electronic device. The first acceleration request includes first hardware information of the first electronic device and information about the target service. The first hardware information includes the type of each hardware accelerator in the first electronic device and the virtualization information of each accelerator. The type of hardware accelerator includes: general-purpose processor type, dedicated accelerator type and coprocessor type. The virtualization information is used to indicate the virtualization method supported by the accelerator. Based on the first hardware information, determine the first target accelerator and the first acceleration strategy that match the target service; Send first feedback information to the first electronic device, the first feedback information including information about the first target accelerator and information about the first acceleration strategy; the first electronic device obtains the information about the first target accelerator and the first acceleration strategy from the second electronic device, and the first electronic device configures the first target accelerator according to the first acceleration strategy so that the first target accelerator processes at least one sub-service in the first target service; Wherein, the step of configuring the first target accelerator by the first electronic device according to the first acceleration strategy includes: In the case where the accelerator type in the first target accelerator includes a coprocessor type and a general-purpose processor type, and the first target accelerator of the coprocessor type supports the SRIOV method, at least one container is created in the general-purpose processor for at least one sub-service in the target service; the container where the target function in the at least one sub-service is located is bound to at least one virtual function (VF) in the coprocessor; and the target driver software is installed in the container where the target function is located. In the case where the accelerator type in the first target accelerator includes a coprocessor type and a general-purpose processor type, and the first target accelerator of the coprocessor type does not support the SRIOV method and does not belong to a preset model, at least one container is created in the general-purpose processor for at least one sub-service of the target service; the container where the target function of the at least one sub-service is located is bound to the coprocessor; the target driver software is installed in the container where the target function is located; shared memory is created in the host system, and the container where the target function is located forwards instructions to other containers through the shared memory so that other containers can call the coprocessor.

16. The method according to claim 15, characterized in that, The step of determining the first target accelerator and the first acceleration strategy matching the target service based on the first hardware information includes: Based on the type of each accelerator, determine the type of accelerator in the first target accelerator; Based on the type of accelerator and virtualization information in the first target accelerator, the first target accelerator and the first acceleration strategy are determined.

17. The method according to claim 16, characterized in that, Determining the type of accelerator in the first target accelerator based on the type of each accelerator includes: Based on the type of each accelerator, detect whether the accelerator of the first electronic device has a dedicated accelerator type; If a dedicated accelerator type is detected, it is determined that the accelerator types in the first target accelerator include dedicated accelerator types and general-purpose processor types; If no dedicated accelerator type is detected, then the presence of a coprocessor type in the accelerator of the first electronic device is detected. If a coprocessor type is detected, then the accelerator type in the first target accelerator is determined to include the coprocessor type and the general processor type; If no dedicated accelerator type and no coprocessor type are detected, then it is determined that the accelerator type in the first target accelerator includes the general-purpose processor type.

18. The method according to claim 17, characterized in that, Based on the type of accelerator and virtualization information in the first target accelerator, the first target accelerator and the first acceleration strategy are determined, including: If the accelerator type in the first target accelerator includes dedicated accelerator type and general processor type, then obtain the virtualization information of each dedicated accelerator; Based on the virtualization information of each dedicated accelerator, detect whether there is a dedicated accelerator that supports the single root virtualization SRIOV method; If a dedicated accelerator supporting the SRIOV method is detected, the first target accelerator is determined to include a first accelerator and a general-purpose processor, and the first acceleration strategy is determined to include a first strategy, wherein the first accelerator is a dedicated accelerator supporting the SRIOV method. If it is detected that there is no dedicated accelerator that supports the SRIOV method and the number of dedicated accelerators is greater than or equal to 1, then it is determined that the first target accelerator includes at least one second accelerator, and the first acceleration strategy includes a second strategy, wherein the second accelerator is a dedicated accelerator that does not support the SRIOV method. The first strategy is used to: instruct the first electronic device to configure the first accelerator in an SRIOV manner; instruct the first electronic device to create at least one container in the general-purpose processor for at least one sub-service in the first target service; instruct the first electronic device to bind the container containing the target function in the at least one sub-service to at least one virtual function (VF) in the first accelerator; and instruct the first electronic device to install target driver software in the container containing the target function. The second strategy is used to: instruct the first electronic device to create at least one container in the general-purpose processor for at least one sub-service of the first target service; instruct the first electronic device to bind the container containing the target function of the at least one sub-service to at least one of the first accelerators; and instruct the first electronic device to install target driver software in the container containing the target function.

19. The method according to claim 17, characterized in that, The step of determining the first target accelerator and the first acceleration strategy based on the type of accelerator and virtualization information in the first target accelerator includes: If the accelerator type in the first target accelerator includes the coprocessor type and the general processor type, then the acceleration capability of the general processor is obtained. Obtain the current hardware acceleration requirements, which include: the computing power of the hardware required for the target function; If it is determined that the acceleration capability meets the hardware acceleration requirements, then the first acceleration strategy is determined based on the virtualization information of the coprocessor. If it is determined that the acceleration capability does not meet the hardware acceleration requirements, then the first acceleration strategy is determined to include a pass-through virtualization strategy.

20. The method according to claim 19, characterized in that, Determining the first acceleration strategy based on the virtualization information of the coprocessor includes: If the virtualization information of the coprocessor indicates that the coprocessor belongs to a preset model, then the first acceleration strategy is determined to include the fifth acceleration strategy.

21. The method according to claim 17, characterized in that, The method further includes: The device receives a second acceleration request sent by the first electronic device. The second acceleration request includes information about the target service and new first hardware information. The second acceleration request is sent when the first electronic device detects that the first target accelerator has malfunctioned or detects that the acceleration capability of the first target accelerator does not meet the current hardware acceleration requirements of the first electronic device. Based on the new first hardware information, a second target accelerator and a second acceleration strategy matching the target service are determined, the second acceleration strategy including instructing the first electronic device to configure the second target accelerator; The information of the second target accelerator and the second acceleration strategy are sent to the first electronic device. The first electronic device configures the second target accelerator according to the second acceleration strategy so that the second target accelerator processes at least one sub-service in the second target service.

22. An electronic device, characterized in that, include: A memory and a processor, wherein the memory is coupled to the processor; The memory stores program instructions that, when executed by the processor, cause the electronic device to perform the target service acceleration method according to any one of claims 1-11, or to perform the target service acceleration method according to any one of claims 12-14, or to perform the target service acceleration method according to any one of claims 15-21.

23. A computer-readable storage medium comprising a computer program, characterized in that, When the computer program is run on the electronic device, the electronic device performs the target service acceleration method according to any one of claims 1-11, or performs the target service acceleration method according to any one of claims 12-14, or performs the target service acceleration method according to any one of claims 15-21.

Images