Technology that provides acceleration capabilities as a service in a disaggregated architecture

Abstract

The technology for providing acceleration functions as services in a decomposed architecture includes a computing device for receiving a request for an accelerated task. The task is associated with a kernel that can be used by an accelerator board that is communicatively coupled to the computing device to perform the task. The computing device also responds to the request and utilizes a database indicating kernels and associated accelerator boards to determine an accelerator board that includes an accelerator device configured with a kernel associated with the request. In addition, the computing device is used to assign the task to a determined accelerator board for execution. Other embodiments are also described and claimed.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 427,268, filed on November 29, 2016, and Indian Provisional Patent Application No. 201741030632, filed on August 30, 2017. Background Art

[0003] Typically, in a data center where workloads (e.g., applications) are assigned to computing devices for execution on behalf of customers (e.g., in a cloud data center), the accelerator device (if any) is local to the general-purpose processor assigned to execute the workload (e.g., on the same board) and can only provide a fixed type of acceleration. Thus, if a particular application executed by the general-purpose processor does not include functions or operations (e.g., tasks) that can utilize the acceleration capabilities of the local accelerator device, the application is executed at a non-accelerated speed and the local accelerator device is not used during the execution of the application, resulting in a waste of resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The concepts described herein are illustrated in the accompanying drawings by way of example and not limitation. For simplicity and clarity of illustration, the elements shown in the drawings are not necessarily drawn to scale. Where deemed appropriate, reference numerals have been repeated in the drawings to indicate corresponding or similar elements.

[0005] Figure 1 is a diagram of a conceptual overview of a data center in which one or more techniques described herein may be implemented, according to various embodiments;

[0006] Figure 2 yes Figure 1 A diagram of an example embodiment of a logical configuration of racks of a data center;

[0007] Figure 3 is a diagram of an example embodiment of another data center in which one or more techniques described herein may be implemented, according to various embodiments;

[0008] Figure 4 is a diagram of another example embodiment of a data center in which one or more techniques described herein may be implemented, according to various embodiments;

[0009] Figure 5 It means that you can Figure 1 , Figure 3 and Figure 4 A diagram of a connection scheme for link layer connections established between various sleds in a data center;

[0010] Figure 6 According to some embodiments, Figure 1-4a diagram of a rack architecture of the architecture of any particular one of the racks shown in ;

[0011] Figure 7 It is possible to Figure 6 Figure 1 shows an example embodiment of a board for use with a rack architecture;

[0012] Figure 8 is a diagram of an example embodiment of a rack architecture for providing support for boards having expansion capabilities;

[0013] Fig. 9 is based on Figure 8 A diagram of an example embodiment of a rack implementing a rack architecture of;

[0014] Fig.10 is designed for use with Fig. 9 Figure 2 shows an example embodiment of a rack for use in conjunction with a plate;

[0015] Fig.11 is a diagram of an example embodiment of a data center in which one or more techniques described herein may be implemented, according to various embodiments;

[0016] Fig.12 is a simplified block diagram of at least one embodiment of a system for providing acceleration functionality as a service.

[0017] Fig.13 yes Fig.12 A simplified block diagram of at least one embodiment of a coordinator server of a system;

[0018] Fig.14 It can be done by Fig.12 and Fig.13 A simplified block diagram of at least one embodiment of an environment established by a coordinator server;

[0019] Figure 15-17 It can be done by Fig.12 and 13 A simplified flowchart of at least one embodiment of a method for providing acceleration functionality as a service performed by a coordinator server of; and

[0020] Fig.18 It can be used with Fig.12 A simplified block diagram of the types of information indicated in the metadata associated with a system acceleration task. DETAILED DESCRIPTION

[0021] Although the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the accompanying drawings and will be described in detail herein. However, it should be appreciated that the concepts of the present disclosure are not intended to be limited to the specific forms disclosed, but on the contrary, all modifications, equivalents and alternatives consistent with the present disclosure and the appended claims are intended to be covered.

[0022] References in the specification to "one embodiment," "an embodiment," "an exemplary embodiment," and the like indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment may or may not necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered to be within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described. Furthermore, it should be appreciated that an item included in a list in the form of "at least one of A, B, and C" may mean (A); (B); (C): (A and B); (A and C); (B and C); or (A, B, and C). Similarly, an item listed in the form of "at least one of A, B, or C" may be (A); (B); (C): (A and B); (A and C); (B and C); or (A, B, and C).

[0023] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on a temporary or non-temporary machine-readable (e.g., computer-readable) storage medium, which may be read and executed by one or more processors. A machine-readable storage medium may be implemented as any storage device, mechanism, or other physical structure (e.g., volatile or non-volatile memory, media disk, or other media device) for storing or sending information in a machine-readable form.

[0024] In the accompanying drawings, some structural or method features may be shown in a specific arrangement and / or order. However, it should be appreciated that such specific arrangement and / or ordering may not be required. On the contrary, in some embodiments, these features may be arranged in a different manner and / or order than shown in the illustrative figures. In addition, the inclusion of structural or method features in a particular accompanying drawing does not mean that such features are required in all embodiments, and these features may not be included or may be combined with other features in some embodiments.

[0025] Figure 1 1 shows a conceptual overview of a data center 100, which may generally represent a data center or other type of computing network in which one or more of the techniques described herein may be implemented according to various embodiments. Figure 1 As shown, data center 100 may generally include a plurality of racks, each of which may accommodate a computing device including a corresponding set of physical resources. Figure 1 In the specific non-limiting example depicted in , data center 100 includes four racks 102A to 102D, which house computing devices including respective groups of physical resources (PCRs) 105A to 105D. According to this example, a set of physical resources 106 of the data center 100 includes various groups of physical resources 105A to 105D distributed among racks 102A to 102D. Physical resources 106 may include various types of resources, such as processors, coprocessors, accelerators, field programmable gate arrays (FPGAs), memory, and storage. Embodiments are not limited to these examples.

[0026] The illustrative data center 100 differs from a typical data center in many ways. For example, in the illustrative embodiment, the circuit board ("sled") on which components such as CPUs, memory and other components are placed is designed to improve thermal performance. In particular, in the illustrative embodiment, the board is shallower than a typical board. In other words, the board is shorter from front to back, where the cooling fan is located. This reduces the length of the path that the air must pass through the components on the board. In addition, the components on the board are spaced farther apart than a typical circuit board, and the components are arranged to reduce or eliminate shadows (i.e., one component is in the air flow path of another component). In the illustrative embodiment, processing components such as processors are located on the top side of the board, while nearby memory such as DIMMs are located on the bottom side of the board. Due to the enhanced airflow provided by this design, the components can operate at higher frequencies and power levels than typical systems, thereby improving performance. In addition, the board is configured to blindly mate with the power and data communication cables in each rack 102A, 102B, 102C, 102D, enhancing their ability to be quickly removed, upgraded, reinstalled and / or replaced. Similarly, the various components located on the board (eg, processors, accelerators, memory, and data storage drives) are configured to be easily upgraded due to their increasing spacing from one another. In an illustrative embodiment, the components also include hardware certification features to prove their authenticity.

[0027] Additionally, in the illustrative embodiment, the data center 100 utilizes a single network architecture (“fabric”) that supports multiple other network architectures, including Ethernet and Omni-Path. In the illustrative embodiment, boards are coupled to switches via optical fiber, which provides higher bandwidth and lower latency than typical twisted pair cabling (e.g., Category 5, Category 5e, Category 6, etc.). Due to the high-bandwidth, low-latency interconnect and network architecture, the data center 100 can pool physically disaggregated resources, such as memory, accelerators (e.g., graphics accelerators, FPGAs, ASICs, etc.), and data storage drives in use and provide them to computing resources (e.g., processors) as needed, enabling the computing resources to access the pooled resources as if they were local. The illustrative data center 100 additionally receives utilization information for various resources, predicts resource utilization for different types of workloads based on past resource utilization, and dynamically reallocates resources based on this information.

[0028] The racks 102A, 102B, 102C, 102D of the data center 100 may include physical design features that facilitate automation of various types of maintenance tasks. For example, the data center 100 may be implemented using racks designed for robotic access, and accept and house resource boards that are robotically manipulable. Additionally, in the illustrative embodiment, the racks 102A, 102B, 102C, 102D include integrated power supplies that receive a voltage greater than a typical voltage for the power supply. The increased voltage enables the power supply to provide additional power to the components on each board, enabling the components to operate at a higher frequency than a typical frequency.

[0029] Figure 2 FIG. 2 shows an exemplary logical configuration of racks 202 of data center 100. Figure 2 As shown, rack 202 can generally accommodate multiple boards, each of which can include a corresponding set of physical resources. Figure 2 In the specific non-limiting example depicted in FIG, rack 202 houses boards 204-1 through 204-4 including a respective set of physical resources 205-1 through 205-4, each set of physical resources forming part of a set of physical resources 206 included in the rack 202. Figure 1, if rack 202 represents, for example, rack 102A, then physical resources 206 can correspond to physical resources 105A included in rack 102A. In the context of this example, physical resources 105A can therefore be composed of a corresponding set of physical resources, including physical storage resources 205-1, physical accelerator resources 205-2, physical memory resources 205-3, and physical computing resources 205-5 included in boards 204-1 to 204-4 of rack 202. Embodiments are not limited to this example. Each board can contain a pool of each of various types of physical resources (e.g., computing, memory, accelerators, storage devices). By having a robot-accessible and robot-manipulable board that includes decomposed resources, each type of resource can be upgraded independently of each other and at its own optimized refresh rate.

[0030] Figure 3 An example of a data center 300 is shown, which may generally represent an example of a data center 300 that may be implemented in accordance with various embodiments. Figure 3 In the specific non-limiting example depicted in FIG. 3 , data center 300 includes racks 302-1 through 302-32. In various embodiments, the racks of data center 300 may be arranged in a manner to define and / or accommodate various access paths. For example, Figure 3 As shown, the racks of the data center 300 can be arranged in a manner that defines and / or accommodates access paths 311A, 311B, 311C, and 311D. In some embodiments, the presence of such access paths generally enables automated maintenance equipment (e.g., robotic maintenance equipment) to physically access computing devices housed in various racks of the data center 300 and perform automated maintenance tasks (e.g., replace failed boards, upgrade boards). In various embodiments, the size of the access paths 311A, 311B, 311C, and 311D, the size of the racks 302-1 to 302-32, and / or one or more other aspects of the physical layout of the data center 300 can be selected to facilitate such automated operations. The embodiments are not limited to this context.

[0031] Figure 4 4 shows an example of a data center 400, which may generally represent a data center that may implement one or more of the techniques described herein in accordance with various embodiments. Figure 4 As shown, data center 400 can feature an optical fabric 412. Optical fabric 412 can generally include a combination of optical signaling media (e.g., optical cables) and optical switching infrastructure via which any particular board in data center 400 can send signals to (and receive signals from) every other board in data center 400. The signaling connections provided by optical fabric 412 to any given board can include connections to other boards in the same rack and boards in other racks. Figure 4 In the specific non-limiting example depicted in FIG. 4 , data center 400 includes four racks 402A to 402D. Racks 402A to 402D house corresponding pairs of boards 404A-1 and 404A-2, 404B-1 and 404B-2, 404C-1 and 404C-2, and 404D-1 and 404D-2. Thus, in this example, data center 400 includes a total of eight boards. Each such board can have a signaling connection with each of the seven other boards in data center 400 through optical fabric 412. For example, via optical fabric 412, board 404A-1 in rack 402A may have signaling connections to board 404A-2 in rack 402A, as well as six other boards 404B-1, 404B-2, 404C-1, 404C-2, 404D-1, and 404D-2 distributed among other racks 402B, 402C, and 402D in data center 400. Embodiments are not limited to this example.

[0032] Figure 5 An overview of a connection scheme 500 is shown, which may generally represent various boards (e.g., Figure 1 , Figure 3 and Figure 4 The link layer connection established between any of the example data centers 100, 300, and 400). The connection scheme 500 can be implemented using an optical structure featuring a dual-mode optical switching infrastructure 514. The dual-mode optical switching infrastructure 514 can generally include a switching infrastructure capable of receiving communications according to multiple link layer protocols through the same unified set of optical signaling media and switching such communications appropriately. In various embodiments, the dual-mode optical switching infrastructure 514 can be implemented using one or more dual-mode optical switches 515. In various embodiments, the dual-mode optical switch 515 can generally include a high-radix switch. In some embodiments, the dual-mode optical switch 515 can include a multi-layer switch, such as a four-layer switch. In various embodiments, the dual-mode optical switch 515 can be characterized by integrated silicon photonics, which enables the dual-mode optical switch to switch communications with significantly reduced latency compared to traditional switch devices. In some embodiments, the dual-mode optical switch 515 can constitute a leaf switch 530 in a leaf-spine structure, which additionally includes one or more dual-mode optical spine switches 520.

[0033] In various embodiments, the dual-mode optical switch is capable of receiving Ethernet protocol communications carrying Internet Protocol (IP packets) and communications according to a second high performance computing (HPC) link layer protocol (e.g., Intel's Omni-Path Architecture, Infiniband) via an optical signaling medium of an optical fabric. Figure 5As reflected, for any particular pair of boards 504A and 504B having an optical signaling connection to an optical fabric, the connection scheme 500 can therefore provide support for link layer connections via Ethernet links and HPC links. Thus, a single high-bandwidth, low-latency switching fabric can support Ethernet and HPC communications. Embodiments are not limited to this example.

[0034] Figure 6 600, which may represent an example of a rack architecture according to some embodiments. Figures 1 to 4 The architecture of any particular one of the racks shown in . Figure 6 As shown, the rack architecture 600 may generally feature a plurality of board spaces into which boards may be inserted, each board space being robot accessible via a rack access area 601. Figure 6 In the particular non-limiting example shown, the rack architecture 600 features five board spaces 603-1 through 603-5. The board spaces 603-1 through 603-5 feature corresponding multi-function connector modules (MPCMs) 616-1 through 616-5.

[0035] Figure 7 An example of a board 704 is shown that may represent this type of board. Figure 7 As shown, board 704 may include a set of physical resources 705, and MPCM 716, which is designed to be inserted into a board space (e.g., Figure 6 The board 704 may be coupled to a mating MPCM when any board space 603-1 to 603-5 is connected. The board 704 may also feature an expansion connector 717. The expansion connector 717 may generally include a socket, a slot, or other type of connection element that can accept one or more types of expansion modules, such as an expansion board 718. By coupling with a mating connector on the expansion board 718, the expansion connector 717 can provide the physical resource 705 with access to the supplemental computing resources 705B residing on the expansion board 718. The embodiments are not limited to this context.

[0036] Figure 8 An example of a rack architecture 800 is shown that may represent a rack architecture that may be implemented to provide a plurality of racks for boards (eg, Figure 7 The board 704) provides support. Figure 8In the specific non-limiting example depicted in , the rack architecture 800 includes seven board spaces 803-1 through 803-7, which feature respective MPCMs 816-1 through 816-7. The board spaces 803-1 through 803-7 include respective main regions 803-1A through 803-7A and respective expansion regions 803-1B through 803-7B. With respect to each such board space, when the respective MPCM is coupled with a mating MPCM of an inserted board, the main region may generally constitute an area of ​​the board space that physically accommodates the inserted board. In the case where the inserted board is configured with such a module, the expansion region may generally constitute an area of ​​the board space that may physically accommodate an expansion module, e.g. Figure 7 Expansion board 718.

[0037] Fig. 9 An example of a rack 902 is shown, which may represent a rack according to some embodiments. Figure 8 The rack architecture 800 is implemented in the rack. Fig. 9 In the specific non-limiting example depicted in FIG. 9 , rack 902 features seven board spaces 903-1 to 903-7, which include respective main regions 903-1A to 903-7A and respective expansion regions 903-1B to 903-7B. In various embodiments, an air cooling system may be used to achieve temperature control in rack 902. For example, Fig. 9 As reflected in , rack 902 can feature multiple fans 919, which are generally arranged to provide air cooling within various board spaces 903-1 to 903-7. In some embodiments, the height of the board space is greater than the traditional "1U" server height. In such an embodiment, fans 919 can generally include relatively slow large diameter cooling fans compared to fans used in traditional rack configurations. Running a larger diameter cooling fan at a lower speed can extend fan life while still providing the same amount of cooling relative to a smaller diameter cooling fan running at a higher speed. The board is physically shallower than traditional rack sizes. In addition, components are arranged on each board to reduce thermal shadows (i.e., not arranged in series along the airflow direction). Therefore, wider and shallower boards allow for an increase in equipment performance because the equipment can operate at a higher thermal envelope (e.g., 250W) due to improved cooling (i.e., no thermal shadows, more space between equipment, larger heat sink space, etc.).

[0038] The MPCMs 916-1 to 916-7 may be configured to provide access to power from corresponding power modules 920-1 to 920-7 to the inserted boards, each of which may draw power from an external power source 921. In some embodiments, the external power source 921 may deliver alternating current (AC) power to the rack 902, and the power modules 920-1 to 920-7 may be configured to convert such AC power to direct current (DC) power for supply to the inserted boards. In some embodiments, for example, the power modules 920-1 to 920-7 may be configured to convert 277 volt AC power to 12 volt DC power to be provided to the inserted boards via the corresponding MPCMs 916-1 to 916-7. Embodiments are not limited to this example.

[0039] The MPCMs 916-1 to 916-7 may also be arranged to provide inserted boards with optical signaling connections to the dual-mode optical switching infrastructure 914, which may be connected to the Figure 5 The optical interconnect loom 923 may be arranged to pass through a support column or other type of load-bearing element of the rack 902. The embodiments are not limited in this context. Because the inserted board is connected to the optical switching infrastructure through the MPCM, resources that are typically expended on manually configuring rack wiring to accommodate the newly inserted board can be saved.

[0040] Fig.10 An example of a board 1004 is shown, which may represent a design for use with a Fig. 9 The board 1004 may be configured to be used in conjunction with the rack 902 of the board 1004. The board 1004 may feature an MPCM 1016 that includes an optical connector 1016A and a power connector 1016B and is designed to couple with a mating MPCM in the board space in conjunction with inserting the MPCM 1016 into the board space. Coupling the MPCM 1016 with such a mating MPCM may enable the power connector 1016 to couple with a power connector included in the mating MPCM. This typically enables the physical resources 1005 of the board 1004 to obtain power from an external source via the power connector 1016 and the power transmission medium 1024 that conductively couples the power connector 1016 to the physical resources 1005.

[0041] Board 1004 may also include dual-mode optical network interface circuitry 1026. Dual-mode optical network interface circuitry 1026 may generally include a circuit capable of Fig. 9 The dual-mode optical switching infrastructure 914 supports a circuit for communicating through an optical signaling medium for each of the multiple link layer protocols. In some embodiments, the dual-mode optical network interface circuit 1026 is capable of Ethernet protocol communications and communications according to a second high performance protocol. In various embodiments, the dual-mode optical network interface circuit 1026 may include one or more optical transceiver modules 1027, each of which is capable of sending and receiving optical signals on each of one or more optical channels. The embodiments are not limited in this context.

[0042] Coupling the MPCM 1016 with a mating MPCM of a board space in a given rack may cause the optical connector 1016A to couple with an optical connector included in the mating MPCM. This may typically establish an optical connection between the board's optical cables and a dual-mode optical network interface circuit 1026 via each of a set of optical channels 1025. The dual-mode optical network interface circuit 1026 may communicate with the physical resources 1005 of the board 1004 via an electrical signaling medium 1028. In addition to the size of the board and the arrangement of components on the board to provide improved cooling and be able to operate in a relatively high thermal envelope (e.g., 250 W), as described above with reference to Fig. 9 As mentioned, in some embodiments, the board may also include one or more additional features to facilitate air cooling, such as heat pipes and / or heat sinks arranged to dissipate heat generated by the physical resources 1005. Fig.10 The exemplary board 1004 depicted in does not feature an expansion connector, but any given board featuring design elements of board 1004 may also feature an expansion connector in accordance with some embodiments. The embodiments are not limited in this context.

[0043] Fig.11 1 shows an example of a data center 1100, which may generally represent an implementation of one or more of the techniques described herein in accordance with various embodiments. Fig.11As reflected, a physical infrastructure management framework 1150A may be implemented to facilitate management of the physical infrastructure 1100A of the data center 1100. In various embodiments, one function of the physical infrastructure management framework 1150A may be to manage automated maintenance functions within the data center 1100, such as using robotic maintenance equipment to provide services for computing devices within the physical infrastructure 1100A. In some embodiments, the physical infrastructure 1100A may feature an advanced telemetry system that performs telemetry reporting that is robust enough to support remote automated management of the physical infrastructure 1100A. In various embodiments, the telemetry information provided by such an advanced telemetry system may support features such as fault prediction / prevention capabilities and capacity planning capabilities. In some embodiments, the physical infrastructure management framework 1150A may also be configured to manage the authentication of physical infrastructure components using hardware certification technology. For example, a robot may verify the authenticity of a component by analyzing information collected from a radio frequency identification (RFID) tag associated with each component to be installed before installation. The embodiments are not limited to this context.

[0044] like Fig.11 As shown, the physical infrastructure 1100A of the data center 1100 may include an optical fabric 1112, which may include a dual-mode optical switching infrastructure 1114. The optical fabric 1112 and the dual-mode optical switching infrastructure 1114 may be respectively Figure 4 The optical structure of 412 and Figure 5 The dual-mode optical switching infrastructure 514 is the same or similar to that of the data center 1100 and can provide high-bandwidth, low-latency, multi-protocol connections between boards in the data center 1100. As described above, reference Figure 1 In various embodiments, the availability of such connectivity can enable the decomposition and dynamic aggregation of resources such as accelerators, memory, and storage. In some embodiments, for example, one or more aggregated accelerator boards 1130 can be included in the physical infrastructure 1100A of the data center 1100, each of which can include a pool of accelerator resources, such as, for example, coprocessors and / or FPGAs, which can be globally accessible to other boards via the optical fabric 1112 and dual-mode optical switching infrastructure 1114.

[0045] In another example, in various embodiments, one or more pooled storage boards 1132 may be included in the physical infrastructure 1100A of the data center 1100, each physical infrastructure 1100A may include a storage resource pool that is globally accessible to other boards via an optical fabric 1112 and a dual-mode optical switching infrastructure 1114. In some embodiments, such pooled storage boards 1132 may include a pool of solid-state storage devices (e.g., solid-state drives (SSDs)). In various embodiments, one or more high-performance processing boards 1134 may be included in the physical infrastructure 110A of the data center 1100. In some embodiments, the high-performance processing board 1134 may include a high-performance processor pool and enhanced air cooling to generate cooling features of a thermal envelope of up to 250W or more. In various embodiments, any given high-performance processing board 1134 may feature an expansion connector 1117 that may accept a far memory expansion board so that the far memory locally available to the high-performance processing board 1134 is decomposed from the processor and the nearby memory contained on the board. In some embodiments, such a high-performance processing board 1134 may be configured with a far memory using an expansion board including low-latency SSD storage. The optical infrastructure allows compute resources on one board to take advantage of remote accelerator / FPGA, memory and / or SSD resources that are disaggregated on boards located in the same rack or any other rack in the data center. Remote resources can be located in the above reference Figure 5 One switch hop or two switch hops in the described spine-and-leaf network architecture. The embodiments are not limited in this context.

[0046] In various embodiments, one or more abstraction layers may be applied to the physical resources of the physical infrastructure 1100A to define a virtual infrastructure, such as a software-defined infrastructure 1100B. In some embodiments, the virtual computing resources 1136 of the software-defined infrastructure 1100B may be allocated to support the provision of cloud services 1140. In various embodiments, a particular set of virtual computing resources 1136 may be grouped to be provided to the cloud services 1140 in the form of SDI services 1138. Examples of cloud services 1140 may include, but are not limited to, software as a service (SaaS) services 1142, platform as a service (PaaS) services 1144, and infrastructure as a service (IaaS) services 1146.

[0047] In some embodiments, a virtual infrastructure management framework 1150B may be used to manage the software defined infrastructure 1100B. In various embodiments, the virtual infrastructure management framework 1150B may be designed to implement workload fingerprinting techniques and / or machine learning techniques in conjunction with managing the allocation of virtual computing resources 1136 and / or SDI services 1138 to cloud services 1140. In some embodiments, the virtual infrastructure management framework 1150B may use / consult telemetry data in conjunction with performing such resource allocation. In various embodiments, an application / service management framework 1150C may be implemented to provide QoS management capabilities for cloud services 1140. The embodiments are not limited in this context.

[0048] Reference now Fig.12 , the system 1210 for providing the acceleration function as a service can be based on the above reference Figure 1 , Figure 3 , Figure 4 and Fig.11 The described data centers 100, 300, 400, 1100 are implemented. In the illustrative embodiment, the system 1210 includes a coordinator server 1220 communicatively coupled to a plurality of boards, including a computing board 1230 and accelerator boards 1240, 1242. One or more of the boards 1230, 1240, 1242 can be grouped into managed nodes, for example, by the coordinator server 1220, to jointly execute a workload, such as an application. A managed node may be embodied as a collection of resources (e.g., physical resources 206), such as computing resources (e.g., physical computing resources 205-4), memory resources (e.g., physical memory resources 205-3), storage resources (e.g., physical storage resources 205-1), or other resources (e.g., physical accelerator resources 205-2), etc., from the same or different boards (e.g., boards 204-1, 204-2, 204-3, 204-4, etc.) or racks (e.g., one or more of racks 302-1 to 302-32). In addition, managed nodes may be established, defined, or "spun up" by the coordinator server 1220 when workloads are assigned to managed nodes or at any other time, and managed nodes may exist regardless of whether any workloads are currently assigned to the managed nodes. The system 1210 may be located in a data center and provide storage and computing services (e.g., cloud services) to client devices 1214 that communicate with the system 1210 over a network 1212. The orchestrator server 1220 may support a cloud operating environment, such as OpenStack, and the managed nodes established by the orchestrator server 1220 may execute one or more applications or processes (ie, workloads) on behalf of a user of the client device 1214, such as in a virtual machine or container.

[0049] In the illustrative embodiment, the computing board 1230 includes a central processing unit (CPU) 1232 (e.g., a processor or other device or circuit capable of performing a series of operations) that executes a workload 1234 (e.g., an application). In the illustrative embodiment, the accelerator board 1240 includes a plurality of accelerator devices 1260, 1262, each of which includes a plurality of cores 1270, 1272, 1274, 1276. Each accelerator device 1260, 1262 may be embodied as any device or circuit capable of accelerating the execution of a function (e.g., a dedicated processor, an FPGA, an ASIC, a graphics processing unit (GPU), reconfigurable hardware, etc.). Each core 1270, 1272, 1274, 1276 may be embodied as a set of code or a configuration of a portion of the corresponding accelerator device 1260, 1262 that causes the accelerator device 1260, 1262 to perform one or more accelerated functions (e.g., encryption operations, compression operations, etc.). Similarly, accelerator board 1242 includes accelerator devices 1264, 1266 and corresponding kernels 1278, 1280, 1282, 1284, similar to accelerator devices 1260, 1262 and kernels 1270, 1272, 1274, 1276. In operation, coordinator server 1220 maintains a database of which kernels are present on which accelerator boards (e.g., on an accelerator device of one of accelerator boards 1240, 1242), receives requests for accelerating portions of a workload (e.g., a task), uses information in the request to determine the type of acceleration associated with the task (e.g., the function to be accelerated), and assigns the task to one or more corresponding accelerator boards 1240, 1242. In addition, to provide additional flexibility, coordinator server 1220 can coordinate the installation and / or removal of kernels from accelerator boards to accommodate requests from compute boards (e.g., compute board 1230) for task acceleration. In this way, system 1210 provides acceleration functionality as a service to the workload, rather than limiting the workload to the acceleration capabilities (if any) of an accelerator device, which may be local to the CPU 1232 executing the workload (e.g., physically located on the computing board 1230).

[0050] Reference now Fig.13, the coordinator server 1220 can be embodied as any type of computing device capable of performing the functions described herein, including receiving a request for accelerating a task associated with a kernel (e.g., kernel 1270) used by an accelerator board (e.g., accelerator board 1240) communicatively coupled to the coordinator server 1220 to execute the task, in response to the request and utilizing a kernel mapping database indicating kernels and associated accelerator boards, determining an accelerator board (e.g., accelerator board 1240) that includes an accelerator device (e.g., accelerator device 1260) configured with the kernel associated with the request, and assigning the task to the determined accelerator board for execution.

[0051] like Fig.13 As shown, the illustrative coordinator server 1220 includes a computing engine 1302, an input / output (I / O) subsystem 1308, a communication circuit 1310, and one or more data storage devices 1314. Of course, in other embodiments, the coordinator server 1220 may include other or additional components, such as components commonly found in computers (e.g., displays, peripherals, etc.). In addition, in some embodiments, one or more of the illustrative components may be incorporated into another component or otherwise form a part of another component.

[0052] The computing engine 1302 may be embodied as any type of device or collection of devices capable of performing the various computing functions described below. In some embodiments, the computing engine 1302 may be embodied as a single device, such as an integrated circuit, an embedded system, a field programmable gate array (FPGA), a system on a chip (SOC), or other integrated system or device. Additionally, in some embodiments, the computing engine 1302 includes or is embodied as a processor 1304 and a memory 1306. The processor 1304 may be embodied as any type of processor capable of performing the functions described herein. For example, the processor 1304 may be embodied as a single-core or multi-core processor, a microcontroller, or other processor or processing / control circuit. In some embodiments, the processor 1304 may be embodied as, include, or be coupled to an FPGA, an application specific integrated circuit (ASIC), reconfigurable hardware or hardware circuitry, or other dedicated hardware, to facilitate performing the functions described herein. Additionally, in an illustrative embodiment, the processor 1304 includes a kernel tracer logic unit 1320, which may be embodied as any circuit or device (e.g., an FPGA, an ASIC, a coprocessor, etc.) capable of offloading operations associated with providing acceleration functions as a service described herein from the processor 1304.

[0053] The main memory 1306 may be embodied as any type of volatile (e.g., dynamic random access memory (DRAM), etc.) or non-volatile memory or data storage device capable of performing the functions described herein. Volatile memory may be a storage medium that requires power to maintain the state of the data stored by the medium. Non-limiting examples of volatile memory may include various types of random access memory (RAM), such as dynamic random access memory (DRAM) or static random access memory (SRAM). One specific type of DRAM that may be used in a memory module is synchronous dynamic random access memory (SDRAM). In certain embodiments, the DRAM of the memory component may conform to standards promulgated by JEDEC, such as JESD79F for DDR SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM, JESD209 for Low Power DDR (LPDDR), JESD209-2 for LPDDR2, JESD209-3 for LPDDR3, and JESD209-4 for LPDDR4 (these standards are available at www.jedec.org). These standards (and similar standards) may be referred to as DDR-based standards, and the communication interfaces of storage devices that implement such standards may be referred to as DDR-based interfaces.

[0054] In one embodiment, the memory device is a block addressable memory device, such as those based on NAND or NOR technology. The memory device may also include a next generation non-volatile device, such as a three-dimensional cross-point memory device (e.g., Intel 3D XPoint TM Memory), or other byte-addressable write-in-place non-volatile memory devices. In one embodiment, the memory device may be or may include a memory device using chalcogenide glass, multi-threshold level NAND flash memory, NOR flash memory, single-level or multi-level phase change memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), antiferroelectric memory, magnetoresistive random access memory (MRAM) memory using memristor technology, resistive memory including metal oxide base, oxygen vacancy base and conductive bridge random access memory (CB-RAM), or spin transfer torque (STT)-MRAM, a device based on spintronic magnetic junction memory, a device based on magnetic tunnel junction (MTJ), a device based on DW (domain wall) and SOT (spin-orbit transfer), a thyristor-based memory device, or a combination of any of the above devices, or other memory. The memory device may refer to the die itself and / or the packaged memory product.

[0055] In some embodiments, a 3D crosspoint memory (e.g., Intel 3D XPoint TM The main memory 1306 may include a transistor-free stackable cross-point architecture in which memory cells are located at the intersection of word lines and bit lines and are individually addressable and in which bit storage is based on changes in bulk resistance. In some embodiments, all or a portion of the main memory 1306 may be integrated into the processor 1304. In operation, the main memory 1306 may store various software and data used during operation, such as task request data, kernel mapping data, telemetry data, applications, programs, libraries, and drivers.

[0056] The compute engine 1302 is communicatively coupled to the other components of the coordinator server 1220 via an I / O subsystem 1308, which may be embodied as circuits and / or components for facilitating input / output operations with the compute engine 1302 (e.g., with the processor 1304 and / or memory 1306) and other components of the coordinator server 1220. For example, the I / O subsystem 1308 may be embodied as or otherwise include a memory controller hub, an input / output control hub, an integrated sensor hub, a firmware device, a communication link (e.g., a point-to-point link, a bus link, wires, cables, optical guides, printed circuit board traces, etc.), and / or other components and subsystems that facilitate input / output operations. In some embodiments, the I / O subsystem 1308 may form part of a system on a chip (SoC) and be incorporated into the compute engine 1302 along with one or more of the processor 1304, the main memory 1306, and the other components of the coordinator server 1220.

[0057] The communication circuit 1310 may be embodied as any communication circuit, device, or collection thereof capable of enabling communication between the coordinator server 1220 and another computing device (e.g., computing board 1230, accelerator boards 1240, 1242, etc.) over the network 1212. The communication circuit 1310 may be configured to use any one or more communication technologies (e.g., wired or wireless communications) and related protocols (e.g., Ethernet, WiMAX, etc.) to achieve this communication.

[0058] The illustrative communication circuit 1310 includes a network interface controller (NIC) 1312, which may also be referred to as a host fabric interface (HFI). The NIC 1312 may be embodied as one or more built-in boards, daughter cards, network interface cards, controller chips, chipsets, or other devices that can be used by the coordinator server 1220 to connect to another computing device (e.g., computing board 1230, accelerator boards 1240, 1242, etc.). In some embodiments, the NIC 1312 may be embodied as part of a system on chip (SoC) including one or more processors, or included on a multi-chip package that also includes one or more processors. In some embodiments, the NIC 1312 may include a local processor (not shown) and / or a local memory (not shown), both of which are local to the NIC 1312. In such an embodiment, the local processor of the NIC 1312 is capable of performing one or more of the functions of the computing engine 1302 described herein. Additionally or alternatively, in such an embodiment, the local memory of the NIC 1312 may be integrated into one or more components of the coordinator server 1220 at the board level, the slot level, the chip level, and / or other levels.

[0059] One or more illustrative data storage devices 1314 may be embodied as any type of device configured for short-term or long-term storage of data, such as memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. Each data storage device 1314 may include a system partition that stores data and firmware code for the data storage device 1314. Each data storage device 1314 may also include an operating system partition that stores data files and executable files for the operating system.

[0060] Additionally or alternatively, the coordinator server 1220 may include one or more peripherals 1316. Such peripherals 1316 may include any type of peripherals typically found in computing devices, such as a display, speakers, mouse, keyboard, and / or other input / output devices, interface devices, and / or other peripherals.

[0061] Reference now Fig.14, the coordinator server 1220 can establish the environment 1400 during operation. The illustrative environment 1400 includes a network communicator 1420 and an acceleration service manager 1430. Each component of the environment 1400 can be embodied as hardware, firmware, software, or a combination thereof. Thus, in some embodiments, one or more components of the environment 1400 can be embodied as a collection of circuits or electronic devices (e.g., a network communicator circuit 1420, an acceleration service manager circuit 1430, etc.). It should be appreciated that in such embodiments, one or more of the network communicator circuit 1420 or the acceleration service manager circuit 1430 can form part of one or more of the compute engine 1302, the kernel tracker logic unit 1320, the communication circuit 1310, the I / O subsystem 1308, and / or other components of the coordinator server 1220. In the illustrative embodiment, the environment 1400 includes task request data 1402, which may be embodied as any data indicating one or more requests received by the coordinator server 1220 from a computing board (e.g., computing board 1230) for accelerating tasks (e.g., one or more functions) associated with all or a portion of a workload. In addition, in the illustrative embodiment, the environment 1400 includes kernel mapping data 1404, which may be embodied as any data indicating kernels associated with the accelerator boards 1240, 1242. In the illustrative embodiment, a kernel is associated with an accelerator board if an accelerator device of the accelerator board is currently configured with a kernel (e.g., a socket of an FPGA is configured with a kernel). Additionally, in the illustrative embodiment, the environment 1400 includes telemetry data 1406, which can be embodied as any data indicating performance (e.g., operations per second, the current amount of total computing capacity of the accelerator device currently being used, etc., referred to herein as utilization load) and other conditions (e.g., power usage) of each accelerator device 1260, 1262, 1264, 1266 of each accelerator board 1240, 1242.

[0062] In the illustrative environment 1400, the network communicator 1420 (which may be embodied in hardware, firmware, software, virtualized hardware, emulation architecture, and / or combinations thereof as described above) is configured to facilitate inbound and outbound network communications (e.g., network traffic, network packets, network flows, etc.) to and from the coordinator server 1220, respectively. To this end, the network communicator 1420 is configured to receive and process data packets from one system or computing device (e.g., computing board 1230) and to prepare and send data packets to another computing device or system (e.g., accelerator board 1240, 1242). Thus, in some embodiments, at least a portion of the functionality of the network communicator 1420 may be performed by the communication circuit 1310, and in the illustrative embodiment, by the NIC 1312.

[0063] The acceleration service manager 1430 (which may be embodied as hardware, firmware, software, virtualized hardware, emulation architecture, and / or a combination thereof) is configured to coordinate receiving requests for accelerating tasks, determine one or more accelerator boards 1240, 1242 for executing the task based on whether the accelerator board 1240, 1242 already has a kernel associated with the task on the accelerator device or has the ability to configure the accelerator device with a kernel (e.g., in an FPGA socket), and assign the task to the determined accelerator board 1240, 1242 for execution. To this end, in an illustrative embodiment, the acceleration service manager 1430 includes a task request manager 1432, a kernel manager 1434, and a utilization manager 1436. In an illustrative embodiment, the task request manager 1432 is configured to receive task requests and determine the characteristics of the task, including the kernel used to accelerate the function of the task, whether the task can be executed by multiple accelerator devices at the same time (e.g., through virtualization, sharing data through virtualized shared memory, etc.), and / or a quality of service target (e.g., target latency, target throughput, etc.). In an illustrative embodiment, the kernel manager 1434 is configured to use the kernel mapping data 1404 to determine which accelerator board 1240, 1242 (if any) already has a kernel (e.g., the accelerator device 1260 of the accelerator board 1240 may already have a slot configured with a kernel). In some embodiments, if the kernel is not present on the accelerator board 1240, 1242, the kernel manager 1434 coordinates that at least one of the accelerator devices of the accelerator board 1240, 1242 is configured with the kernel. In an illustrative embodiment, the utilization manager 1436 is configured to collect telemetry data 1406 and analyze the telemetry data 1406 to help determine which accelerator board 1240, 1242 should be selected to accelerate the task. For example, if multiple accelerator boards 1240, 1242 currently have cores associated with a task request, the utilization manager 1436 can analyze the telemetry data 1406 to determine which accelerator board 1240, 1242 has sufficient utilization capacity (e.g., utilization load meets a predefined threshold) to meet the quality of service target (e.g., target latency for completing the task).

[0064] Reference now Fig.15, the coordinator server 1220 can perform method 1500 in operation to provide acceleration functionality as a service. Method 1500 begins with box 1502, where the coordinator server 1220 determines whether to enable the acceleration functionality as a service. In an illustrative embodiment, if the coordinator server 1220 is communicatively coupled to one or more accelerator boards (e.g., accelerator boards 1240, 1242) and a workload has been assigned to a computing board (workload 1234 is assigned to computing board 1230), the coordinator server 1220 may determine to enable the acceleration functionality as a service. In other embodiments, the coordinator server 1220 may determine whether to enable the acceleration functionality as a service based on other factors. In any case, in response to determining to enable the acceleration functionality as a service, the method 1500 proceeds to box 1504, where the coordinator server 1220 may receive a request (e.g., a task request) for accelerating a task associated with a kernel. In doing so, the coordinator server 1220 may receive a request from a computing board (e.g., computing board 1230) executing a workload (e.g., workload 1234), as shown in block 1506. In addition, when receiving the request, the coordinator server 1220 may receive the request including metadata indicating characteristics and parameters of the task (e.g., input data, settings, etc.), as shown in block 1508. Fig.18 The information 1800 indicated in the metadata may also include the type of workload for which the task is to be accelerated (e.g., workloads supporting convolutional neural networks, data compression workloads, data encryption workloads, etc.) and characteristics, such as quality of service requirements and / or virtualization capabilities of the task. Return to reference Fig.15 In block 1510, the coordinator server 1220 may receive a request with metadata indicating a virtualization capability of a task (e.g., whether the task can be divided into functions that can be executed by separate virtual machines). In an illustrative embodiment, the coordinator server 1220 may receive metadata indicating a concurrent execution capability (e.g., whether the functions can be executed at the same time, such as in separate virtual machines), as shown in block 1512. Additionally or alternatively, the coordinator server 1220 may receive a request with metadata indicating a number of virtualizable functions of the task, as shown in block 1514.

[0065] Additionally or alternatively, upon receiving the request, the coordinator server 1220 may receive the request with metadata indicating target quality of service data (e.g., according to a service level agreement (SLA)), as shown in block 1516. For example, as shown in block 1518, the metadata may indicate a target latency (e.g., a maximum number of milliseconds that may elapse before a particular function is completed). As another example, the metadata may indicate a target throughput (e.g., a minimum number of operations per second), as shown in block 1520. In an illustrative embodiment, the request identifies a kernel associated with the task, as shown in block 1522. Thus, and as shown in block 1524, in some embodiments, the coordinator server 1220 may receive a request including the kernel itself, such as in the form of a bitstream, as shown in block 1526, or executable code embodying the kernel, as shown in block 1528. In an illustrative embodiment, the request includes an identifier of the kernel (e.g., a universally unique identifier (UUID)), as shown in block 1530. In block 1532, the coordinator server 1220 determines a subsequent course of action based on whether a task request was received. If no task request is received, the method 1500 loops back to block 1502 to determine whether to continue enabling the acceleration function as a service. Otherwise, the method 1500 proceeds to Fig.16 Block 1534 where the coordinator server 1220 determines whether the core associated with the task already exists in the accelerator board 1240 , 1242 .

[0066] Reference now Fig.16 When determining whether the kernel already exists in the accelerator board, the coordinator server 1220 may compare the kernel's identifier to a kernel mapping database that indicates kernel identifiers and accelerator boards (e.g., accelerator boards on which the corresponding kernel exists), as shown in block 1536. In doing so, the coordinator server 1220 may perform a comparison with the kernel identifier included in the task request (e.g., from Fig.151530 of the kernel identifier of the task request), as shown in box 1538. Optionally, the coordinator server 1220 can perform a comparison with a hash of the kernel included in the task request (e.g., a hash generated by the coordinator server 1220 of the bitstream or executable code), as shown in box 1540. In box 1542, the coordinator server 1220 determines a subsequent course of action based on whether the kernel already exists in the accelerator board 1240, 1242. If not, the method 1500 proceeds to box 1544, where the coordinator server 1220 determines an accelerator board that has capacity to configure the kernel. In doing so, the coordinator server 1220 can request the accelerator board 1240, 1242 to determine whether there is unused capacity, as shown in box 1546. In doing so, and as shown in block 1548, the coordinator server 1220 may query the accelerator boards 1240, 1242 to determine if there are unused FPGA slots (e.g., if one or more of the accelerator devices 1260, 1262, 1264, 1266 are FPGAs). As shown in block 1550, the coordinator server 1220 may request the accelerator board 1220 to generate capacity by removing kernels that do not meet a threshold usage level (e.g., the kernel has not been used within a predefined time period). For example, when generating capacity, the bitstream of the kernel to be removed may be saved in memory, but the gates of the corresponding FPGA slots may be specified for reprogramming based on the bitstream for the new kernel. Subsequently, the coordinator server 1220 sends the kernel (e.g., a bitstream or executable code embodying the kernel) to the determined accelerator board for configuration (e.g., for programming), as shown in block 1552. Thereafter, the method 1500 proceeds to block 1554. Wherein, the coordinator server 1220 updates the kernel mapping database (e.g., kernel mapping data 1404) to indicate that the kernel is associated with the determined accelerator board. Subsequently, or if the coordinator server 1220 determines in box 1542 that the kernel already exists in the accelerator board, the method 1500 proceeds to box 1556, where the coordinator server 1220 receives telemetry data (e.g., telemetry data 1406) indicating the utilization load (e.g., the amount of available acceleration capacity used) of each accelerator board 1240, 1242. In doing so, in an illustrative embodiment, the coordinator server 1220 receives telemetry data indicating the utilization load of each accelerator device of each accelerator board 1240, 1242. Although described as occurring at a specific position in the sequence in method 1500, it should be understood that the coordinator server 1220 can receive telemetry data 1406 at any time, including concurrently with other operations performed in method 1500.

[0067] Reference now Fig.17, the method 1500 continues to block 1560, where the coordinator server 1220 selects an accelerator board 1240, 1242 to perform the task, which is configured with a core and has a utilization load that meets a predefined threshold. In doing so, the coordinator server 1220 may select an accelerator board 1240, 1242 with a utilization load that meets a threshold associated with a target quality of service (e.g., a current utilization load of less than 80% to meet a target latency associated with one quality of service or a throughput or utilization load of less than 60% to meet a target latency or throughput associated with a second quality of service that is higher than the first quality of service requirement), as shown in block 1562. As shown in block 1564, the coordinator server 1220 may compare the telemetry data 1406 for each accelerator board with the predefined threshold. In some embodiments, the coordinator server 1220 may select an accelerator board based on additional criteria (e.g., target power usage) that may be indicated in the task request metadata in a configuration setting from an administrator of the system 1210 or from another source, as shown in block 1566. In some embodiments, the coordinator server 1220 may select multiple accelerator boards 1240 , 1242 to perform a task (eg, a task may be divided into multiple virtualized functions across multiple accelerator devices and accelerator boards), as shown in block 1568 .

[0068] Subsequently, in block 1570, the coordinator server 1220 allocates the task associated with the task request to the selected accelerator board for execution. In doing so, in the illustrative embodiment, the coordinator server 1220 sends the allocation request to the selected accelerator board, as shown in block 1572. As shown in block 1574, the coordinator server 1220 may send a message including metadata from the task request (e.g., in Fig.15 When sending the allocation request with metadata, the coordinator server 1220 may send a request including the quality of service target data (e.g., Fig.15 In addition or alternatively, the coordinator server 1220 may send a request including the virtualization data (e.g., the quality of service target data received in block 1516 of FIG. 1570 ), as shown in block 1576. Fig.151578). In addition, as shown in box 1580, the coordinator server 1220 can send an allocation request including concurrent execution data, as shown in box 1580, shared virtual memory address data, as shown in box 1582, and / or identifiers of multiple accelerator devices and / or accelerator boards, wherein the multiple accelerator devices and / or accelerator boards are used to share data to perform tasks (e.g., via shared virtual memory addresses and / or by sending data directly from the accelerator device and / or accelerator board to another). Subsequently, the method 1500 loops back to Fig.15 Box 1502, where the coordinator server 1220 determines whether to continue to enable the acceleration function as a service.

[0069] Example

[0070] The following provides illustrative examples of the techniques disclosed herein. Implementations of these techniques may include any one or more of the examples described below, and any combination.

[0071] Example 1 includes a computing device comprising: a computing engine for: receiving a request for an accelerated task, wherein the task is associated with a kernel that can be used by an accelerator board communicatively coupled to the computing device to perform the task; in response to the request and utilizing a database indicating kernels and associated accelerator boards, determining an accelerator board of an accelerator device configured with the kernel associated with the request; and assigning the task to the determined accelerator board for execution.

[0072] Example 2 includes the subject matter of Example 1, and wherein determining an accelerator board that includes an accelerator device configured with the kernel includes: determining that an accelerator board is not currently associated with the kernel; determining an accelerator board that has capacity to be configured with the kernel; sending the kernel to the determined accelerator board for configuration; and updating the database to indicate that the kernel is associated with the determined accelerator board.

[0073] Example 3 includes the subject matter of any of Examples 1 and 2, and wherein determining an accelerator board having capacity to be configured with the core comprises: determining a field programmable gate array (FPGA) having an unused slot to be configured with the core.

[0074] Example 4 includes the subject matter of any of Examples 1-3, and wherein determining an accelerator board that includes an accelerator device configured with the kernel comprises: determining a plurality of accelerator boards, each accelerator board of the plurality of accelerator boards including an accelerator device configured with the kernel; and wherein the computing engine is further used to select an accelerator board that is configured with the kernel and has a utilization load that satisfies a predefined threshold for executing the task; and wherein assigning the task to the determined accelerator board comprises assigning the task to the selected accelerator board.

[0075] Example 5 includes the subject matter of any of Examples 1-4, and wherein the computing device is communicatively coupled to the plurality of accelerator boards, and the computing engine is further used to: receive data from each accelerator board indicating an utilization load associated with each accelerator board; and wherein selecting an accelerator board configured with the core and having an utilization load that satisfies a predefined threshold for executing the task includes comparing the data received from each accelerator board to the predefined threshold.

[0076] Example 6 includes the subject matter of any of Examples 1-5, and wherein receiving a request to accelerate a task comprises receiving a request including metadata indicating characteristics and parameters of the task.

[0077] Example 7 includes the subject matter of any of Examples 1-6, and wherein receiving a request including metadata indicating characteristics and parameters of the task includes: receiving a request including metadata indicating a target quality of service associated with the task; wherein determining an accelerator board including an accelerator device configured with a kernel includes determining a plurality of accelerator boards, each accelerator board of the plurality of accelerator boards including an accelerator device configured with the kernel; and wherein the computing engine is further configured to select an accelerator board configured with the kernel and having a utilization load that satisfies a predefined threshold associated with the target quality of service for performing the task

[0078] Example 8 includes the subject matter of any of Examples 1-7, and wherein receiving the request including metadata indicating characteristics and parameters of the task comprises receiving the request including metadata indicating virtualization capabilities of the task.

[0079] Example 9 includes the subject matter of any of Examples 1-8, and wherein receiving a request including metadata indicating characteristics and parameters of the task includes: receiving a request including metadata indicating concurrent execution capability of the task; and wherein assigning the task includes assigning the task to multiple accelerator boards for concurrent execution.

[0080] Example 10 includes the subject matter of any of Examples 1-9, and wherein assigning the task to multiple accelerator boards for concurrent execution comprises: sending an allocation request to the multiple accelerator boards, wherein the allocation request includes identifiers of the multiple accelerator boards assigned to the task to enable data to be shared between the assigned accelerator boards when the task is executed concurrently.

[0081] Example 11 includes the subject matter of any of Examples 1-10, and wherein allocating the task to multiple accelerator boards for concurrent execution comprises: sending an allocation request to the multiple accelerator boards, wherein the allocation request includes shared virtual memory address data that the multiple accelerator boards can use to share data in a virtual memory when the task is executed concurrently.

[0082] Example 12 includes the subject matter of any of Examples 1-11, and wherein receiving the request comprises: receiving a request including an identifier of the kernel; and wherein, in response to the request and utilizing a database indicating kernels and associated accelerator boards, determining an accelerator board including an accelerator device configured with the kernel associated with the request comprises comparing the received identifier with a kernel identifier in the database.

[0083] Example 13 includes the subject matter of any of Examples 1-12, and wherein receiving a request comprises: receiving a request including a kernel; and wherein, in response to the request and utilizing a database indicating kernels and associated accelerator boards, determining an accelerator board including an accelerator device configured with the kernel associated with the request comprises obtaining a hash of the received kernel; and comparing the hash to a kernel identifier in the database.

[0084] Example 14 includes the subject matter of any of Examples 1-13, and wherein receiving the request comprises receiving the request from a computing board executing a workload associated with the task.

[0085] Example 15 includes a method comprising: receiving, by a computing device, a request for an accelerated task, wherein the task is associated with a kernel that can be used by an accelerator board communicatively coupled to the computing device to perform the task; determining, by the computing device and in response to the request and utilizing a database indicating kernels and associated accelerator boards, an accelerator board including an accelerator device configured with the kernel associated with the request; and assigning, by the computing device, the task to the determined accelerator board for execution.

[0086] Example 16 includes the subject matter of Example 15, and wherein determining an accelerator board including an accelerator device configured with the kernel comprises: determining that an accelerator board is not currently associated with the kernel; determining an accelerator board having capacity to be configured with the kernel; sending the kernel to the determined accelerator board for configuration; and updating the database to indicate that the kernel is associated with the determined accelerator board.

[0087] Example 17 includes the subject matter of any of Examples 15 and 16, and wherein determining an accelerator board having capacity to be configured with the core comprises: determining a field programmable gate array (FPGA) having an unused slot to be configured with the core.

[0088] Example 18 includes the subject matter of any of Examples 15-17, and wherein determining an accelerator board including an accelerator device configured with the kernel comprises: determining a plurality of accelerator boards, each accelerator board of the plurality of accelerator boards including an accelerator device configured with the kernel; and the method further comprises: selecting, by the computing device, an accelerator board configured with the kernel and having a utilization load that satisfies a predefined threshold for executing a task; and wherein assigning the task to the determined accelerator board comprises assigning the task to the selected accelerator board.

[0089] Example 19 includes the subject matter of any of Examples 15-18, and wherein the computing device is communicatively coupled to a plurality of accelerator boards, the method further comprising receiving, by the computing device and from each accelerator board, data indicating an utilization load associated with each accelerator board; and wherein selecting an accelerator board configured with the kernel and having an utilization load that satisfies a predefined threshold for executing the task comprises comparing the data received from each accelerator board to the predefined threshold.

[0090] Example 20 includes the subject matter of any of Examples 15-19, and wherein receiving a request to accelerate a task comprises receiving a request including metadata indicating characteristics and parameters of the task.

[0091] Example 21 includes the subject matter of any of Examples 15-20, and wherein receiving a request including metadata indicating characteristics and parameters of the task includes: receiving a request including metadata indicating a target quality of service associated with the task; and wherein determining an accelerator board including an accelerator device configured with a kernel includes determining a plurality of accelerator boards, each of the plurality of accelerator boards including an accelerator device configured with the kernel; and the method further includes selecting, by the computing device, an accelerator board configured with the kernel and having a utilization load that satisfies a predefined threshold associated with the target quality of service for performing the task.

[0092] Example 22 includes the subject matter of any of Examples 15-21, and wherein receiving a request including metadata indicating characteristics and parameters of the task comprises: receiving a request including metadata indicating virtualization capabilities of the task.

[0093] Example 23 includes the subject matter of any of Examples 15-22, and wherein receiving a request including metadata indicating characteristics and parameters of the task includes: receiving a request including metadata indicating concurrent execution capability of the task; and wherein assigning the task includes assigning the task to multiple accelerator boards for concurrent execution.

[0094] Example 24 includes the subject matter of any of Examples 15-23, and wherein assigning the task to multiple accelerator boards for concurrent execution comprises: sending an allocation request to the multiple accelerator boards, wherein the allocation request includes identifiers of the multiple accelerator boards assigned to the task to enable data to be shared between the assigned accelerator boards when the task is executed concurrently.

[0095] Example 25 includes the subject matter of any of Examples 15-24, and wherein allocating the task to multiple accelerator boards for concurrent execution includes: sending an allocation request to the multiple accelerator boards, wherein the allocation request includes shared virtual memory address data that the multiple accelerator boards can use to share data in a virtual memory when the task is executed concurrently.

[0096] Example 26 includes the subject matter of any of Examples 15-25, and wherein receiving the request comprises: receiving a request including an identifier of the kernel; and wherein, in response to the request and utilizing a database indicating kernels and associated accelerator boards, determining an accelerator board including an accelerator device configured with the kernel associated with the request comprises comparing the received identifier with a kernel identifier in the database.

[0097] Example 27 includes the subject matter of any of Examples 15-26, and wherein receiving a request comprises receiving a request including a kernel; and wherein, in response to the request and utilizing a database indicating kernels and associated accelerator boards, determining an accelerator board including an accelerator device configured with the kernel associated with the request comprises obtaining a hash of the received kernel; and comparing the hash to a kernel identifier in the database.

[0098] Example 28 includes the subject matter of any of Examples 15-27, and wherein receiving the request comprises receiving the request from a computing board executing a workload associated with the task.

[0099] Example 29 includes one or more machine-readable storage media comprising a plurality of instructions stored thereon that in response to being executed cause a computing device to perform the method of any of Examples 15-28.

[0100] Example 30 includes a computing device including means for performing the method of any of Examples 15-28.

[0101] Example 31 includes a computing device comprising: one or more processors; one or more memory devices storing a plurality of instructions, which, when executed by the one or more processors, cause a network switch to perform the method of any one of Examples 15-28.

[0102] Example 32 includes a computing device comprising a network communicator circuit for receiving a request for an accelerated task, wherein the task is associated with a kernel that can be used by an accelerator board that is communicatively coupled to the computing device to perform the task; and an acceleration service manager circuit for, in response to the request and utilizing a database indicating kernels and associated accelerator boards, determining an accelerator board that includes an accelerator device configured with the kernel associated with the request; and assigning the task to the determined accelerator board for execution.

[0103] Example 33 includes the subject matter of Example 32, and wherein determining an accelerator board including an accelerator device configured with the kernel comprises: determining that an accelerator board is not currently associated with the kernel; determining an accelerator board having capacity to be configured with the kernel; sending the kernel to the determined accelerator board for configuration; and updating the database to indicate that the kernel is associated with the determined accelerator board.

[0104] Example 34 includes the subject matter of any of Examples 32 and 33, and wherein determining an accelerator board having capacity to be configured with the core comprises: determining a field programmable gate array (FPGA) having an unused slot to be configured with the core.

[0105] Embodiment 35 includes the subject matter of any one of Embodiments 32-34, and wherein determining an accelerator board including an accelerator device configured with the kernel comprises: determining a plurality of accelerator boards, each accelerator board of the plurality of accelerator boards including an accelerator device configured with the kernel; and wherein the acceleration service manager circuit is further used to select an accelerator board configured with the kernel and having a utilization load that meets a predefined threshold for executing the task; and wherein assigning the task to the determined accelerator board comprises assigning the task to the selected accelerator board.

[0106] Example 36 includes the subject matter of any of Examples 32-35, and wherein the computing device is communicatively coupled to a plurality of accelerator boards, and the acceleration service manager circuit is further for receiving data from each accelerator board indicating an utilization load associated with each accelerator board; and wherein selecting an accelerator board that is configured with a kernel and has an utilization load that satisfies a predefined threshold for executing a task comprises comparing the data received from each accelerator board to the predefined threshold.

[0107] Example 37 includes the subject matter of any of Examples 32-36, and wherein receiving a request to accelerate a task comprises: receiving a request including metadata indicating characteristics and parameters of the task.

[0108] Example 38 includes the subject matter of any of Examples 32-37, and wherein receiving a request including metadata indicating characteristics and parameters of the task includes: receiving a request including metadata indicating a target quality of service associated with the task; wherein determining an accelerator board including an accelerator device configured with a kernel includes determining a plurality of accelerator boards, each of the plurality of accelerator boards including an accelerator device configured with a kernel; and wherein the acceleration service manager circuit is further used to select an accelerator board configured with a kernel and having a utilization load that meets a predefined threshold associated with the target quality of service for performing the task.

[0109] Example 39 includes the subject matter of any of Examples 32-38, and wherein receiving a request including metadata indicating characteristics and parameters of the task comprises: receiving a request including metadata indicating virtualization capabilities of the task.

[0110] Example 40 includes the subject matter of any of Examples 32-39, and wherein receiving a request including metadata indicating characteristics and parameters of the task includes: receiving a request including metadata indicating concurrent execution capability of the task; and wherein assigning the task includes assigning the task to multiple accelerator boards for concurrent execution.

[0111] Example 41 includes the subject matter of any of Examples 32-40, and wherein assigning the task to multiple accelerator boards for concurrent execution includes sending an allocation request to the multiple accelerator boards, wherein the allocation request includes identifiers of the multiple accelerator boards assigned to the task so that data can be shared between the assigned accelerator boards when the task is executed concurrently.

[0112] Example 42 includes the subject matter of any of Examples 32-41, and wherein allocating the task to multiple accelerator boards for concurrent execution includes sending an allocation request to the multiple accelerator boards, wherein the allocation request includes shared virtual memory address data that the multiple accelerator boards can use to share data in a virtual memory when the task is executed concurrently.

[0113] Example 43 includes the subject matter of any of Examples 32-42, and wherein receiving the request comprises receiving a request including an identifier of the kernel; and wherein, in response to the request and utilizing a database indicating kernels and associated accelerator boards, determining an accelerator board including an accelerator device configured with the kernel associated with the request comprises comparing the received identifier with a kernel identifier in the database.

[0114] Example 44 includes the subject matter of any of Examples 32-43, and wherein receiving a request comprises: receiving a request including a kernel; and wherein, in response to the request and utilizing a database indicating kernels and associated accelerator boards, determining an accelerator board including an accelerator device configured with the kernel associated with the request comprises obtaining a hash of the received kernel; and comparing the hash to a kernel identifier in the database.

[0115] Example 45 includes the subject matter of any of Examples 32-44, and wherein receiving the request comprises receiving the request from a computing board executing a workload associated with the task.

[0116] Example 46 includes a computing device comprising: circuitry for receiving a request for an accelerated task, wherein the task is associated with a kernel that can be used by an accelerator board that is communicatively coupled to the computing device to perform the task; a unit for determining, in response to the request and utilizing a database indicating kernels and associated accelerator boards, an accelerator board of an accelerator device that is configured with the kernel associated with the request; and circuitry for assigning, by the computing device, the task to the determined accelerator board for execution.

[0117] Example 47 includes the subject matter of Example 46, and wherein the unit for determining an accelerator board including an accelerator device configured with the kernel includes: circuitry for determining that an accelerator board is not currently associated with the kernel; circuitry for determining an accelerator board that has capacity to be configured with the kernel; circuitry for sending the kernel to the determined accelerator board for configuration; and circuitry for updating the database to indicate that the kernel is associated with the determined accelerator board.

[0118] Example 48 includes the subject matter of any of Examples 46 and 47, and wherein the circuitry for determining an accelerator board having capacity to be configured with the core comprises circuitry for determining a field programmable gate array (FPGA) having an unused slot to be configured with the core.

[0119] Example 49 includes the subject matter of any of Examples 46-48, and wherein the unit for determining an accelerator board including an accelerator device configured with the kernel includes circuitry for determining a plurality of accelerator boards, each of the plurality of accelerator boards including an accelerator device configured with the kernel; and the computing device further includes circuitry for selecting an accelerator board configured with the kernel and having a utilization load that satisfies a predefined threshold for executing a task; and wherein the circuitry for assigning the task to the determined accelerator board includes circuitry for assigning the task to the selected accelerator board.

[0120] Example 50 includes the subject matter of any of Examples 46-49, and wherein the computing device is communicatively coupled to a plurality of accelerator boards, the computing device further comprising circuitry for receiving, from each accelerator board, data indicating a utilization load associated with each accelerator board; and wherein the means for selecting an accelerator board configured with a core and having a utilization load that satisfies a predefined threshold for executing a task comprises circuitry for comparing the data received from each accelerator board to the predefined threshold.

[0121] Example 51 includes the subject matter of any of Examples 46-50, and wherein the circuitry for receiving a request to accelerate a task comprises circuitry for receiving a request including metadata indicating characteristics and parameters of the task.

[0122] Example 52 includes the subject matter of any of Examples 46-51, and wherein the circuit for receiving a request including metadata indicating characteristics and parameters of a task includes a circuit for receiving a request including metadata indicating a target quality of service associated with the task; and wherein the unit for determining an accelerator board including an accelerator device configured with a kernel includes a circuit for determining a plurality of accelerator boards, each of the plurality of accelerator boards including an accelerator device configured with a kernel; and the computing device further includes a circuit for selecting an accelerator board configured with a kernel and having a utilization load that satisfies a predefined threshold associated with the target quality of service for performing the task.

[0123] Example 53 includes the subject matter of any of Examples 46-52, and wherein the circuitry for receiving a request including metadata indicating characteristics and parameters of the task includes circuitry for receiving a request including metadata indicating virtualization capabilities of the task.

[0124] Example 54 includes the subject matter of any of Examples 46-53, and wherein the circuit for receiving a request including metadata indicating characteristics and parameters of a task includes a circuit for receiving a request including metadata indicating concurrent execution capabilities of the task; and wherein the circuit for allocating tasks includes a circuit for allocating tasks to multiple accelerator boards for concurrent execution.

[0125] Example 55 includes the subject matter of any of Examples 46-54, and wherein the circuit for assigning tasks to multiple accelerator boards for concurrent execution includes a circuit for assigning allocation requests to the multiple accelerator boards, wherein the allocation requests include: identifiers of the multiple accelerator boards assigned to the task to enable data to be shared between the assigned accelerator boards when the tasks are executed concurrently.

[0126] Example 56 includes the subject matter of any of Examples 46-55, and wherein the circuitry for assigning tasks to multiple accelerator boards for concurrent execution includes sending an allocation request to the multiple accelerator boards, wherein the allocation request includes shared virtual memory address data that the multiple accelerator boards can use to share data in a virtual memory when the tasks are executed concurrently.

[0127] Example 57 includes the subject matter of any of Examples 46-56, and wherein the circuit for receiving a request includes a circuit for receiving a request including an identifier of a kernel; and wherein the unit for responding to the request and determining, using a database indicating kernels and associated accelerator boards, an accelerator board including an accelerator device configured with the kernel associated with the request includes a circuit for comparing the received identifier with a kernel identifier in the database.

[0128] Example 58 includes the subject matter of any of Examples 46-57, and wherein the circuit for receiving a request includes circuitry for receiving a request including a kernel; and wherein the unit for responding to the request and determining, using a database indicating kernels and associated accelerator boards, an accelerator board including an accelerator device configured with the kernel associated with the request includes circuitry for obtaining a hash of the received kernel; and circuitry for comparing the hash to a kernel identifier in the database.

[0129] Example 59 includes the subject matter of any of Examples 46-58, and wherein the circuitry for receiving the request comprises circuitry for receiving the request from a computing board executing a workload associated with the task.

Claims

1. A computing device, comprising: A computational engine that is used to: receiving a request for an accelerated task, wherein the task is associated with a kernel usable by an accelerator board communicatively coupled to the computing device to perform the task; In response to the request, and utilizing a database and telemetry data indicating kernels and associated accelerator boards, determining an accelerator board including an accelerator device configured with the kernel associated with the request, wherein the telemetry data indicates a utilization load of the accelerator device of the accelerator board; and assigning the task to a determined accelerator board for execution, Wherein, receiving a request for accelerating a task includes: receiving a request including metadata indicating a target quality of service associated with the task; wherein determining an accelerator board including an accelerator device configured with the kernel comprises determining a plurality of accelerator boards, each accelerator board of the plurality of accelerator boards including an accelerator device configured with the kernel; and The computing engine is further configured to select an accelerator board configured with the core and having a utilization load that satisfies a predefined threshold associated with the target quality of service for executing the task.

2. The computing device of claim 1, wherein: Determining an accelerator board including an accelerator device configured with the kernel includes: determining that an accelerator board is not currently associated with the core; determining an accelerator board having capacity to be configured with the core; sending the kernel to the determined accelerator board for configuration; and The database is updated to indicate that the core is associated with the determined accelerator board.

3. The computing device of claim 2, wherein: Determining an accelerator board having capacity to be configured with the core includes determining a field programmable gate array (FPGA) having an unused slot to be configured with the core.

4. The computing device of claim 1, wherein: Determining an accelerator board including an accelerator device configured with the kernel includes: determining a plurality of accelerator boards, each accelerator board of the plurality of accelerator boards including an accelerator device configured with the kernel; and wherein the computing engine is further configured to select an accelerator board configured with the core and having a utilization load that satisfies a predefined threshold for executing the task; and Wherein, allocating the task to the determined accelerator board includes allocating the task to a selected accelerator board.

5. The computing device of claim 4, wherein: The computing device is communicatively coupled to the plurality of accelerator boards, and the computing engine is further configured to: receiving, from each accelerator board, data indicative of a utilization load associated with each accelerator board; as well as Wherein, selecting an accelerator board configured with the core and having a utilization load that satisfies a predefined threshold for executing the task includes comparing data received from each accelerator board with the predefined threshold.

6. The computing device of claim 1, wherein: Receiving a request to accelerate a task includes receiving a request including metadata indicating characteristics and parameters of the task.

7. The computing device of claim 6, wherein: Receiving a request including metadata indicating characteristics and parameters of the task includes receiving a request including metadata indicating virtualization capabilities of the task.

8. The computing device of claim 6, wherein: Receiving a request including metadata indicating characteristics and parameters of the task includes: receiving a request including metadata indicating concurrent execution capabilities of the task; and Wherein, allocating the task includes allocating the task to multiple accelerator boards for concurrent execution.

9. The computing device of claim 8, wherein: Allocating the task to multiple accelerator boards for concurrent execution includes sending an allocation request to the multiple accelerator boards, wherein the allocation request includes identifiers of the multiple accelerator boards allocated to the task to enable data to be shared between the allocated accelerator boards when the task is executed concurrently.

10. The computing device of claim 8, wherein: Allocating the task to multiple accelerator boards for concurrent execution includes sending an allocation request to the multiple accelerator boards, wherein the allocation request includes shared virtual memory address data that the multiple accelerator boards can use to share data in a virtual memory when the task is concurrently executed.

11. The computing device of claim 1, wherein: Receiving the request includes: receiving a request including an identifier of the kernel; and Wherein, in response to the request and utilizing a database indicating cores and associated accelerator boards, determining an accelerator board including an accelerator device configured with a core associated with the request comprises comparing the received identifier with a core identifier in the database.

12. A computing device comprising: circuitry for receiving a request for an accelerated task, wherein the task is associated with a kernel usable by an accelerator board communicatively coupled to the computing device to perform the task; means for determining, in response to the request and utilizing a database and telemetry data indicating kernels and associated accelerator boards, an accelerator board including an accelerator device configured with the kernel associated with the request, wherein the telemetry data indicates a utilization load of the accelerator device of the accelerator board; and circuitry for assigning, by the computing device, the task to the determined accelerator board for execution, Wherein, the circuit for receiving a request for accelerating a task comprises: a circuit for receiving a request including metadata indicating a target quality of service associated with the task; and wherein the means for determining an accelerator board comprising an accelerator device configured with the kernel comprises circuitry for determining a plurality of accelerator boards, each accelerator board of the plurality of accelerator boards comprising an accelerator device configured with the kernel; and The computing device also includes circuitry for selecting an accelerator board configured with the core and having a utilization load that satisfies a predefined threshold associated with the target quality of service for executing the task.

13. The computing device of claim 12, wherein: The means for determining an accelerator board comprising an accelerator device configured with the kernel comprises: circuitry for determining that an accelerator board is not currently associated with the core; circuitry for determining an accelerator board having capacity to be configured with the core; circuitry for sending the kernel to the determined accelerator board for configuration; and Circuitry for updating the database to indicate that the core is associated with the determined accelerator board.

14. The computing device of claim 13, wherein: The circuitry for determining an accelerator board having capacity to be configured with the core includes circuitry for determining a field programmable gate array (FPGA) having an unused socket to be configured with the core.

15. The computing device of claim 12, wherein: The means for determining an accelerator board including an accelerator device configured with the kernel includes: circuitry for determining a plurality of accelerator boards, each accelerator board of the plurality of accelerator boards including an accelerator device configured with the kernel; and The computing device also includes circuitry for selecting an accelerator board configured with the core and having a utilization load that satisfies a predefined threshold for performing the task; and Wherein, the circuit for allocating the task to the determined accelerator board includes a circuit for allocating the task to a selected accelerator board.

16. The computing device of claim 15, wherein: The computing device is communicatively coupled to the plurality of accelerator boards, the computing device further comprising: circuitry for receiving, from each accelerator board, data indicative of a utilization load associated with each accelerator board; and Wherein, the means for selecting an accelerator board configured with the core and having a utilization load that satisfies a predefined threshold for executing the task comprises circuitry for comparing data received from each accelerator board with the predefined threshold.

17. The computing device of claim 12, wherein: The circuitry for receiving a request to accelerate a task includes circuitry for receiving a request including metadata indicative of characteristics and parameters of the task.

18. The computing device of claim 17, wherein: The circuitry for receiving a request including metadata indicative of characteristics and parameters of the task includes circuitry for receiving a request including metadata indicative of virtualization capabilities of the task.

19. The computing device of claim 17, wherein: The circuitry for receiving a request including metadata indicating characteristics and parameters of the task includes: circuitry for receiving a request including metadata indicating concurrent execution capabilities of the task; Wherein, the circuit for distributing the tasks includes a circuit for distributing the tasks to a plurality of accelerator boards for concurrent execution.

20. The computing device of claim 19, wherein: The circuit for assigning the task to multiple accelerator boards for concurrent execution includes a circuit for sending an allocation request to the multiple accelerator boards, wherein the allocation request includes identifiers of the multiple accelerator boards assigned to the task to enable data to be shared among the assigned accelerator boards when the task is executed concurrently.

21. The computing device of claim 19, wherein: The circuitry for allocating the task to multiple accelerator boards for concurrent execution includes sending an allocation request to the multiple accelerator boards, wherein the allocation request includes shared virtual memory address data that the multiple accelerator boards can use to share data in a virtual memory when the task is executed concurrently.

22. The computing device of claim 12, wherein: The circuitry for receiving the request includes circuitry for receiving a request including an identifier of the core; as well as Wherein, the means for determining, in response to the request and utilizing a database indicating cores and associated accelerator boards, an accelerator board comprising an accelerator device configured with the core associated with the request comprises circuitry for comparing the received identifier with core identifiers in the database.

23. A method comprising: Receiving, by a computing device, a request for an accelerated task, wherein the task is associated with a kernel usable by an accelerator board communicatively coupled to the computing device to perform the task; determining, by the computing device and in response to the request, an accelerator board including an accelerator device configured with the kernel associated with the request and utilizing a database and telemetry data indicating kernels and associated accelerator boards, wherein the telemetry data indicates a utilization load of the accelerator device of the accelerator board; and allocating, by the computing device, the task to the determined accelerator board for execution, Wherein, receiving, by the computing device, a request for accelerating the task comprises: receiving, by the computing device, a request including metadata indicating a target quality of service associated with the task; wherein determining, by the computing device, an accelerator board including an accelerator device configured with the kernel comprises determining, by the computing device, a plurality of accelerator boards, each accelerator board of the plurality of accelerator boards including an accelerator device configured with the kernel; and The method further includes selecting, by the computing device, an accelerator board configured with the core and having a utilization load that satisfies a predefined threshold associated with the target quality of service for executing the task.

24. The method of claim 23, wherein: Determining an accelerator board including an accelerator device configured with the kernel includes: determining that an accelerator board is not currently associated with the core; determining an accelerator board having capacity to be configured with the core; sending the kernel to the determined accelerator board for configuration; and The database is updated to indicate that the core is associated with the determined accelerator board.

25. The method of claim 24, wherein: Determining an accelerator board having capacity to be configured with the core includes determining a field programmable gate array (FPGA) having an unused slot to be configured with the core.

26. The method of claim 23, wherein: Determining an accelerator board including an accelerator device configured with the kernel includes determining a plurality of accelerator boards, each accelerator board of the plurality of accelerator boards including an accelerator device configured with the kernel; as well as The method further includes selecting, by the computing device, an accelerator board configured with the core and having a utilization load that satisfies a predefined threshold for executing the task; as well as Wherein, allocating the task to the determined accelerator board includes allocating the task to a selected accelerator board.

Images