Selective execution of workloads using hardware accelerators
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- MICROSOFT TECHNOLOGY LICENSING LLC
- Filing Date
- 2024-05-16
- Publication Date
- 2026-06-16
Smart Images

Figure 2026519380000001 
Figure 2026519380000002 
Figure 2026519380000003
Abstract
Claims
1. Step 610: A client application (102, 104, or 106) directly sends a command to a hardware accelerator (170, 180, or 190) for the execution of a workload, wherein the command includes an indicator of expected performance from the hardware accelerator (170, 180, or 190), and the workload is executable by an compute core (160) accessible by the client application (102, 104, or 106) or by the hardware accelerator (170, 180, or 190). Step 620: When a retry response is received from the hardware accelerator (170, 180, or 190), the client application (102, 104, or 106) executes the workload using the compute core (160) accessible to the client application (102, 104, or 106), and after the hardware accelerator (170, 180, or 190) determines that it cannot meet the performance expectations, the hardware accelerator (170, 180, or 190) is configured to directly provide the retry response to the client application (102, 104, or 106). Methods that include...
2. The method according to claim 1, further comprising the hardware accelerator executing the workload instead of providing the client application with the retry response after determining that the hardware accelerator can meet the performance expectations.
3. The method according to claim 1, wherein the expected performance value includes the amount of time required for the hardware accelerator to execute the workload.
4. The method according to claim 1, wherein the expected performance value includes the maximum time required for the hardware accelerator to send the command itself.
5. The method according to claim 1, wherein the hardware accelerator includes command queues, and the performance expectation includes a full state criterion or workload criterion associated with one or more of the command queues.
6. The method according to claim 1, wherein the hardware accelerator enables a client application to access a virtual function for at least one physical function associated with the hardware accelerator, and the performance expectation includes a full state criterion or workload criterion associated with one or more of the virtual functions.
7. The method according to claim 1, wherein the performance expectation includes a full state criterion or workload criterion associated with the hardware accelerator.
8. The method according to claim 1, wherein the workload includes a copy workload, a fill workload, an encryption workload, a decryption workload, a compression workload, a decompression workload, a cyclic redundancy check (CRC) generation workload, or a sequence including at least two of the aforementioned workloads.
9. An accelerator portal (110) for enabling multiple client applications (102, 104, 106) to access one or more of multiple shared hardware accelerators (170, 180, or 190), wherein each of the multiple client applications (102, 104, 106) can execute a workload by using a compute core (160) or by using one of the multiple shared hardware accelerators (170, 180, or 190), and Among the plurality of shared hardware accelerators (170, 180, 190), a hardware accelerator (170, 180, or 190) configured to receive commands for executing a workload from a client application (102, 104, or 106) via a shared bus system coupled to the computing core (160) and the plurality of shared hardware accelerators (170, 180, or 190), wherein the command includes an indicator of expected performance from the hardware accelerator (170, 180, or 190), and the workload is executable by the computing core (160) accessible to the client application (102, 104, or 106) or by the hardware accelerator (170, 180, or 190), and The client application (102, 104, or 106) is configured to execute the workload using the compute core (160) accessible to the client application (102, 104, or 106) when it receives a retry response from the hardware accelerator (170, 180, or 190), and is configured to provide the retry response directly to the client application (102, 104, or 106) after the hardware accelerator (170, 180, or 190) has determined that it cannot meet the performance expectations. A system (100) including this.
10. The system according to claim 9, wherein, after determining that the hardware accelerator can meet the performance expectations, the hardware accelerator is configured to execute the workload instead of providing the client application with the retry response.
11. The system according to claim 9, wherein the performance expectation includes the amount of time required for the hardware accelerator to execute the workload.
12. The system according to claim 9, wherein the expected performance value includes the maximum time required for the hardware accelerator to send the command itself.
13. The system according to claim 9, wherein the hardware accelerator enables a client application to access a virtual function for at least one physical function associated with the hardware accelerator, and the performance expectation includes a full state criterion or workload criterion associated with one or more of the virtual functions.
14. The system according to claim 9, wherein the hardware accelerator includes a command queue, and the performance expectation includes a full state criterion or workload criterion associated with one or more of the command queues.
15. The system according to claim 9, wherein the performance expectation includes a full-load criterion or workload criterion associated with the hardware accelerator.