Patent Description:
There is a need for methods and systems to allow harvesting of resources in distributed computing systems, including cloud computing systems.

<CIT> discloses a method and system for providing a distributed technical computing environment for distributing technical computing tasks from a technical computing client to technical computing workers for execution of the tasks on one or more computers systems. Tasks can be defined on a technical computing client, and the tasks organized into jobs. The technical computing client can directly distribute tasks to one or more technical computing workers. Furthermore, the technical computing client can submit tasks, or jobs comprising tasks, to an automatic task distribution mechanism that distributes the tasks automatically to one or more technical computing workers providing technical computing services. The technical computing worker performs technical computing of tasks and the results of the execution of tasks may be provided to the technical computing client. Data associated with the tasks is managed by a programmable interface associated with a data storage repository. The interface allows the various entities of the distributed technical computing environment to access data services performable by the interface or by a file system or a database and database management system associated with the data.

Furthermore, <CIT> discloses a method including receiving, at a first router of a plurality of routers, a first message from the plurality of routers. The first message includes a designated router priority and a weight for each respective router. Based on the designated router priorities, a designated router is elected and a one or more eligible group designated routers are determined. The method determines whether the first router is the designated router or the at least one eligible group designated router. If the first router is the designated router, the first router provides a second message to the remaining routers indicating the eligible group designated routers and their weights.

In one aspect of the present disclosure relates to a method in a system including at least one host server and at least one interface card configured to interface with a network or a storage, where the at least one host server comprises a processor having a first instruction set architecture (ISA) and the at least one interface card comprises a processor having a second ISA. The method may include designating at least one type of resource, associated with the at least one host server for harvesting by compute entities configured for execution using the processor having the second ISA, where the at least one host server is configured to execute compute entities requiring execution by the processor having the first ISA. The method may further include in response to a request for accessing the at least one type of resource by a compute entity, executing on the processor having the second ISA, automatically allowing the compute entity to access the at least one type of resource associated with the at least one host server.

In another aspect, the present disclosure relates to a method in a system including at least one host server and at least one interface card configured to interface with a network or a storage, where the at least one host server comprises a processor having a first instruction set architecture (ISA) and the at least one interface card comprises a processor having a second ISA. The method may include the at least one host server designating at least one type of resource, associated with the at least one host server for harvesting by compute entities configured for execution using the processor having the second ISA, where the host server is configured to execute virtual machines requiring execution by the processor having the first ISA, and where the at least one type of resource may include at least one of a host memory and an I/O device. The method may further include a first hypervisor associated with the at least one host server sharing control information with a second hypervisor associated with the at least one interface card to enable access to the portion of the host memory and the portion of the I/O device. The method may further include in response to a request for accessing the at least one type of resource by a compute entity, executing on the processor having the second ISA, automatically allowing the compute entity to access the at least one type of resource associated with the at least one host server.

In yet another aspect, not covered by the claims, the present disclosure relates to a distributed computing system including a host server comprising a processor having a first instruction set architecture (ISA), where the host server is configured to service compute entities corresponding to at least one tenant, and where each of the compute entities is required to execute using the processor having the first ISA. The distributed computing system may further include an interface card, coupled to the host server, comprising a processor having a second ISA. The distributed computing system may further include a system configured to: (<NUM>) allow designation of at least one type of resource, associated with the host server for harvesting by compute entities configured for execution using the processor having the second ISA, (<NUM>) allow sharing of control information between a first hypervisor associated with the host server and a second hypervisor with the interface card, and (<NUM>) in response to a request for accessing the at least one type of resource by a compute entity, executing on the processor having the second ISA, automatically allow the compute entity to access the at least one type of resource associated with the at least one host server.

This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter, defined by the claims.

Examples described in this disclosure relate to enabling the harvesting of unused resources in a distributed computing system. Certain examples relate to the harvesting of resources designated by a host server in a cloud computing environment. Additional examples relate to harvesting resources of a host server, designated by the host server as unallocated resources, to which an interface card, such as a smart network interface card (smartNIC) is attached. The harvesting of the unallocated resources may allow the use of smartNIC, or smartNIC-like devices, to offer virtual machines (VMs), containers, micro-VMs, microservices, unikernels for serverless functions, or other similar functionality. The host server may be any server in a cloud computing environment that is configured to serve tenants or other subscribers of the cloud computing service. In certain examples, the host server may include x86 processors and the smartNIC may include an ARM® system-on-chip (SoC). The resources that can be harvested may include memory/storage resources, networking resources, and power/cooling resources. Thus, in some scenarios, instead of deploying new ARM®-based servers, the ARM®-based smartNIC may operate as an ARM®-based server that can harvest resources from the x86-based host servers.

<FIG> shows a system <NUM> for harvesting unused resources in accordance with one example. System <NUM> may include a host server <NUM> coupled via a bus <NUM> to an interface card <NUM>. System <NUM> may be implemented as a server or a rack of servers, such that host server <NUM> and interface card <NUM> may be installed in the same rack or a similar structure. In one example, bus <NUM> may correspond to the Peripheral Interconnect Express (PCI Express) bus. Host server <NUM> may include one or more processors having an instruction set architecture (ISA). The processors may be configured to provide at least some form of compute functionality. As an example, host server <NUM> may include CISC processor(s) <NUM> that correspond to a complex instruction set computer (CISC) type of ISA. Example CISC processors may include x86 processors or the like. Interface card <NUM> may be configured to primarily provide a networking or storage functionality to host server <NUM>. In this example, interface card <NUM> may include RISC processor(s) <NUM> that correspond to a reduced instruction set computer (RISC) type of ISA. Example RISC processors <NUM> may include ARM®-based processors.

With continued reference to <FIG>, host server <NUM> may be configured to execute instructions corresponding to hypervisor <NUM>. Hypervisor <NUM> may further be configured to interface with virtual machines (VMs) (e.g., VM <NUM>, <NUM>, and VM <NUM>). Instructions corresponding to the VMs may be executed using any of CISC processor(s) <NUM>. Interface card <NUM> may be configured to execute instructions corresponding to hypervisor <NUM>. Hypervisor <NUM> may further be configured to interface with virtual machines (VMs) (e.g., VM <NUM>, <NUM>, and VM <NUM>). Instructions corresponding to the VMs may be executed using any of RISC processor(s) <NUM>. Host server <NUM> may be coupled via a bus system <NUM> to interface card <NUM>. Hypervisor <NUM> may share control information with hypervisor <NUM> via control path <NUM>. Control path <NUM> may correspond to a path enabled via bus system <NUM> or another bus system (not shown). Each of hypervisor <NUM> and hypervisor <NUM> may be a kernel-based virtual machine (KVM) hypervisor, a Hyper-V hypervisor, or another type of hypervisor. Although <FIG> shows system <NUM> as including a certain number of components arranged and coupled in a certain way, it may include fewer or additional components arranged and coupled differently. In addition, the functionality associated with system <NUM> may be distributed or combined, as needed. Moreover, although <FIG> describes the access to the unused resources by VMs, other types of compute entities, such as containers, micro-VMs, microservices, unikernels for serverless functions, may access the unused resources associated with the host server in a like manner. As used herein, the term "compute entity" encompasses, but is not limited to, any executable code (in the form of hardware, firmware, software, or in any combination of the foregoing) that implements a functionality, an application, a service, a microservice, a container, a unikernel for serverless computing, or a part of the aforementioned.

In certain examples of the present disclosure, to harvest unused resources from the host server, the operating system (or hypervisor) running on the ARM®-based server (e.g., host server <NUM>) would have to cooperate with the operating system running on the host server. As an example, the operating system or the hypervisor may cooperate with the host server to be able to borrow unused memory and disk space. In this example, the control path (e.g., control path <NUM>) would require involvement from both parties at the OS/hypervisor level. Once the resources have been assigned to the ARM®-based interface card, the compute entities (e.g., virtual machines) running on the ARM®-based interface card may access the resources made available by the host server using load/store instructions or remote direct memory access (RDMA), depending on the capabilities of the card. In certain examples, both the storage resource and the network resources can be accessed using peer to peer (P2P) functionality, which may be implemented as part of certain interface cards.

With respect to the harvesting of the unused memory (e.g., DRAM) associated with the host server, at a broad level, there may be two ways for a compute entity (e.g., a virtual machine (VM)) running on the ARM®-based interface card to access the host server's memory: (i) using direct mapping, where load or store accesses are translated to the PCI Express transactions by the hardware associated with the system, or (ii) using swapping, where access to the unmapped pages cause hardware exceptions, which are handled by the hypervisor.

In certain examples, the methods and systems described herein may be deployed in cloud computing environments. Cloud computing may refer to a model for enabling on-demand network access to a shared pool of configurable computing resources. For example, cloud computing can be employed in the marketplace to offer ubiquitous and convenient on-demand access to the shared pool of configurable computing resources. The shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly. A cloud computing model can be composed of various characteristics such as, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud computing model may be used to expose various service models, such as, for example, Hardware as a Service ("HaaS"), Software as a Service ("SaaS"), Platform as a Service ("PaaS"), and Infrastructure as a Service ("IaaS"). A cloud computing model can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.

<FIG> shows a system <NUM> for harvesting unused resources in accordance with one example. System <NUM> may be configured to allow the harvesting of resources using direct mapping. System <NUM> may include a host server <NUM> coupled to a PCI Express bridge <NUM> that supports non-transparent bridge (NTB) functionality. The NTB bridge functionality may be used to allow system <NUM> to operate in the direct access mode. PCI Express bridge <NUM> may be coupled via PCI Express bus <NUM> to a network interface card <NUM>. PCI Express bridge <NUM> may further be coupled via PCI Express bus <NUM> to a storage interface card <NUM>. Host server <NUM> may include CISC processor(s) <NUM>, memory <NUM>, and a controller <NUM>. PCI Express bridge <NUM> may include a peer-<NUM>-peer (P2P/NTB) controller <NUM>, NTB port <NUM>, NTB port <NUM>, P2P port <NUM>, P2P port <NUM>, and P2P port <NUM>, interconnected via bus system <NUM>. Network interface card <NUM> may include RISC processor(s) <NUM>, memory <NUM>, controller <NUM>, MMU <NUM>, and network port(s) <NUM>, interconnected via bus system <NUM>. Storage interface card <NUM> may include RISC processor(s) <NUM>, memory <NUM>, controller <NUM>, MMU <NUM>, and storage controller <NUM>, interconnected via bus system <NUM>.

With continued reference to <FIG>, in this example, busses <NUM> and <NUM> may correspond to PCI Express busses capable of functioning in accordance with the PCI Express specification, including with support for non-transparent bridging. The transactions may be routed using address routing, ID-based routing (e.g., using bus, device, and function numbers), or implicit routing using messages. The transaction types may include transactions associated with memory read/write, I/O read/write, configuration read/write, and messaging operations. The endpoints of the PCI Express system may be configured using base address registers (BARs). The type of BAR may be configured as a BAR for memory operations or I/O operations. Other set up and configuration may also be performed, as needed. The hardware associated with PCI Express system (e.g., the root complexes, NTB ports, P2P ports) may further provide functionality to enable the performance of the memory read/write operations and I/O operations. As an example, address translation logic associated with the PCI Express system may be used for address translation for packet processing, including packet forwarding or packet dropping. In certain examples, busses <NUM> and <NUM> may further support InfiniBand® (or similar functionality) over the PCI Express bus system. This may allow the offloading of the transport layer and other layers needed for communication via busses <NUM> and <NUM> into hardware, such as integrated circuits. Busses <NUM> and <NUM> may further support RDMA over Converged Ethernet (RoCE) to allow RDMA operations over the Ethernet network.

Still referring to <FIG>, using PCI Express transactions, system <NUM> may allow memory or I/O accesses via PCI Express systems. In this example, a hypervisor executing on host server <NUM> may map a memory region associated with memory <NUM> into the guest address space of a virtual machine executing on RISC processor(s) <NUM> or <NUM>. When a loading of data is needed by the VM, the load is directly translated by MMU <NUM> and controller <NUM> (or by MMU <NUM> and controller <NUM>) into a PCI Express transaction. The PCI Express transactions concerning load from a memory (e.g., a DRAM) may include NTB port <NUM> (or NTB port <NUM>) receiving the PCI Express packets and forwarding them via P2P/NTB controller <NUM> to controller <NUM> for accessing data stored in memory <NUM>, which is associated with host server <NUM>.

With continued reference to <FIG>, in one example, controller <NUM> may implement bound checking to ensure that the access to memory <NUM> is secure. Thus, controller <NUM> may check to see whether the virtual address is accessible to the specific type of incoming packet. Each region of memory <NUM> that may be harvested may have a key (e.g., rkey) associated with it. The rkey may not to be passed as part of the incoming packet. Controller <NUM> (associated with CISC processor(s) <NUM>) may receive the key, and then look up a table to determine if the key matches. The matching of the key and the bound check may be required before granting access to the unused memory associated with CISC processor(s) <NUM>.

Similarly, the PCI Express transaction concerning I/O access (e.g., access to SSD <NUM>, HD <NUM>, or other resource(s) <NUM>) may include NTB port <NUM> (or NTB port <NUM>) receiving the PCI Express packets and forwarding them via P2P/NTB controller <NUM> to a P2P controller (e.g., any of P2P controllers <NUM>, <NUM>, or <NUM>) for accessing data stored in an I/O device (e.g., an SSD, an HD, or other I/O devices), which is associated with host server <NUM>. The forwarding may also include address translation by the PCI Express system.

With continued reference to <FIG>, when the storing of data is needed as part of the VM, the store may be directly translated by MMU <NUM> and controller <NUM> (or by MMU <NUM> and controller <NUM>) into a PCI Express transaction. The PCI Express transactions concerning store to a memory (e.g., a DRAM) may include NTB port <NUM> (or NTB port <NUM>) receiving the PCI Express packets and forwarding them via P2P/NTB controller <NUM> to controller <NUM> for storing data in memory <NUM>, which is associated with host server <NUM>. Similarly, the PCI Express transaction concerning I/O access (e.g., access to SSD <NUM>, HD <NUM>, or other resource(s) <NUM>) may include NTB port <NUM> (or NTB port <NUM>) receiving the PCI Express packets and forwarding them via P2P/NTB controller <NUM> to a P2P controller (e.g., any of P2P controllers <NUM>, <NUM>, or <NUM>) for storing data in an I/O device (e.g., an SSD, an HD, or other I/O devices), which is associated with host server <NUM>. Although <FIG> shows system <NUM> as including a certain number of components arranged and coupled in a certain way, it may include fewer or additional components arranged and coupled differently. In addition, the functionality associated with system <NUM> may be distributed or combined, as needed. As an example, although <FIG> shows NTB ports and P2P ports to enable the performance of the memory read/write operations and I/O operations, other types of interconnects may also be used to enable such functionality. Moreover, although <FIG> describes the access to the unused resources by VMs, other types of compute entities, such as containers, micro-VMs, microservices, unikernels for serverless functions, may access the unused resources associated with the host server in a like manner.

<FIG> shows another system <NUM> for harvesting unused resources in accordance with one example. System <NUM> may be configured to allow the harvesting of resources using swapping of pages. In one example, system <NUM> may include a host server <NUM> coupled via a PCI Express bus system <NUM> to a network interface card <NUM> and a storage interface card <NUM>. Host server <NUM> may include CISC processor(s) <NUM>, memory <NUM>, and a controller <NUM>. Network interface card <NUM> may include RISC processor(s) <NUM>, memory <NUM>, controller <NUM>, MMU <NUM>, and network port(s) <NUM>, interconnected via bus system <NUM>. Storage interface card <NUM> may include RISC processor(s) <NUM>, memory <NUM>, controller <NUM>, MMU <NUM>, and storage controller <NUM>, interconnected via bus system <NUM>.

With continued reference to <FIG>, in this example system, any load/store operations associated with the virtual machines being executed by RISC processor(s) <NUM> or <NUM> may be enabled using Remote Direct Memory Access (RDMA) operations between a memory (or an I/O device) associated with host server <NUM> and the RISC processors. In one example, the transfer of any data from the memory associated with host server <NUM> to the virtual machine being executed by RISC processor(s) <NUM> or <NUM> may be accomplished by an operation performed via PCI Express bus system <NUM>. In certain examples, bus <NUM> may further support InfiniBand® (or similar functionality) over the PCI Express bus system. This may allow the offloading of the transport layer and other layers needed for communication via busses <NUM> and <NUM> into hardware, such as integrated circuits. Busses <NUM> and <NUM> may further support RDMA over Converged Ethernet (RoCE) to allow RDMA operations over the Ethernet network.

In this example, prior to any such memory operations (or I/O operations) being performed, control information may be exchanged between host server <NUM> and an interface card (e.g., any of interface cards <NUM> and <NUM>). The exchange of information may occur between hypervisors (e.g., the hypervisors shown in <FIG>). Some of the control information may relate to host server <NUM> designating memory space that could be accessed by a virtual machine being executed using the RISC processors (e.g., an ARM®-core based system-on-chip (SoC) included as part of an interface card). In addition, the memory management unit (or similar functionality) associated with the interface card may be allowed to access host-side page tables or other memory map tables. Access to unmapped pages may cause hardware exceptions, such as page faults. The hypervisor may access host memory and install page table mappings, after moving the remote page to the local memory associated with the interface card(s).

In one example, memory <NUM> or memory <NUM> may act as a cache for the compute entities being executed using the processors associated with the interface cards. Assuming the compute entity requests access to a page that is mapped, then that may be viewed as a cache hit and the content of the page may be accessed by the compute entity. On the other hand, if the page is not mapped, then it may be viewed as a cache miss. In this scenario, a page may first be evicted from memory <NUM> or <NUM>. This process may include a store of the evicted page to memory <NUM>. The page that is being accessed may then be provided by host server <NUM> to the requesting compute entity as long as it passes other requirements discussed earlier.

Still referring to <FIG>, as noted earlier, as part of system <NUM>, loads and stores may be performed using RDMA. RDMA may allow copying of the data directly from the memory of one system (e.g., host server <NUM>) into that of another (e.g., any of the interface cards) without any involvement of either system's operating system. This way, interface cards that support RDMA may achieve the zero-copy benefit by transferring data directly to, or from, the memory space of processes, which may eliminate the extra data copy between the application memory and the data buffers in the operating system. In other words, in this example, by using address translation/mapping across the various software/hardware layers, only one copy of the data may be stored in a memory (or an I/O device) associated with the host server.

With continued reference to <FIG>, in one example, the hypervisor associated with host server <NUM> may allocate certain memory space in memory <NUM> for use by virtual machines executing using the RISC processor(s) <NUM> or RISC processor(s) <NUM>. MMU <NUM> (or MMU <NUM>) may perform address translation between the virtual address space associated with the virtual machines executing using the RISC processor(s) <NUM> or RISC processor(s) <NUM> and memory space in memory <NUM>. As noted earlier, the hypervisor associated with host server <NUM> may designate memory space in memory <NUM> in a manner that certain memory space is not accessible to any of the virtual machines being executed using RISC processor(s) <NUM> or RISC processor(s) <NUM>. Similarly, using RDMA, virtual machines being executed by RISC processor(s) <NUM> or RISC processor(s) <NUM> may access other I/O devices associated with the host server, including storage resources(s) <NUM> and networking resource(s) <NUM>. Although <FIG> shows system <NUM> as including a certain number of components arranged and coupled in a certain way, it may include fewer or additional components arranged and coupled differently. In addition, the functionality associated with system <NUM> may be distributed or combined, as needed. Also, in addition to memory, disk, and network resources, it may be possible to harvest cooling (no active fan) and the unused power of the host server (e.g. host server <NUM>). Moreover, although <FIG> describes the access to the unused resources by VMs, other types of compute entities, such as containers, micro-VMs, microservices, unikernels for serverless functions, may access the unused resources associated with the host server in a like manner.

The harvesting of the unused resources associated with any of the host servers may be offered via systems deployed in a data center or other such computing facilities. <FIG> shows a system environment <NUM> for harvesting unused resources in accordance with one example. In this example, system environment <NUM> may correspond to a portion of a data center. As an example, the data center may include several clusters of racks including platform hardware, such as server nodes, storage nodes, networking nodes, or other types of nodes. Server nodes may be connected to switches to form a network. The network may enable connections between each possible combination of switches. System environment <NUM> may include server1 <NUM> and server2 <NUM>. System environment <NUM> may further include data center related functionality <NUM>, including deployment/monitoring <NUM>, directory/identity services <NUM>, load balancing <NUM>, data center controllers <NUM> (e.g., software defined networking (SDN) controllers and other controllers), and routers/switches <NUM>. Server1 <NUM> may include host processor(s) <NUM>, host hypervisor <NUM>, memory <NUM>, storage interface controller(s) (SIC(s)) <NUM>, cooling <NUM>, network interface controller(s) (NIC(s)) <NUM>, and storage disks <NUM> and <NUM>. Server2 <NUM> may include host processor(s) <NUM>, host hypervisor <NUM>, memory <NUM>, storage interface controller(s) (SIC(s)) <NUM>, cooling <NUM>, network interface controller(s) (NIC(s)) <NUM>, and storage disks <NUM> and <NUM>. Server1 <NUM> may be configured to support virtual machines, including VM1 <NUM>, VM2 <NUM>, and VMN <NUM>. The virtual machines may further be configured to support applications, such as APP1 <NUM>, APP2 <NUM>, and APPN <NUM>. Server2 <NUM> may be configured to support virtual machines, including VM1 <NUM>, VM2 <NUM>, and VMN <NUM>. The virtual machines may further be configured to support applications, such as APP1 <NUM>, APP2 <NUM>, and APPN <NUM>.

With continued reference to <FIG>, in one example, system environment <NUM> may be enabled for multiple tenants using the Virtual eXtensible Local Area Network (VXLAN) framework. Each virtual machine (VM) may be allowed to communicate with VMs in the same VXLAN segment. Each VXLAN segment may be identified by a VXLAN Network Identifier (VNI). Although <FIG> shows system environment <NUM> as including a certain number of components arranged and coupled in a certain way, it may include fewer or additional components arranged and coupled differently. In addition, the functionality associated with system environment <NUM> may be distributed or combined, as needed. Moreover, although <FIG> describes the access to the unused resources by VMs, other types of compute entities, such as containers, micro-VMs, microservices, unikernels for serverless functions, may access the unused resources associated with the host server in a like manner.

<FIG> shows a block diagram of a computing platform <NUM> (e.g., for implementing certain aspects of harvesting of the unused resources) in accordance with one example. Computing platform <NUM> may include a processor <NUM>, I/O devices <NUM>, memory <NUM>, display <NUM>, sensors <NUM>, database <NUM>, and networking interfaces <NUM>, which may be interconnected via bus <NUM>. Processor <NUM> may execute instructions stored in memory <NUM>. I/O devices <NUM> may include components such as a keyboard, a mouse, a voice recognition processor, or touch screens. Memory <NUM> may be any combination of non-volatile storage or volatile storage (e.g., flash memory, DRAM, SRAM, or other types of memories). Display <NUM> may be any type of display, such as LCD, LED, or other types of display. Sensors <NUM> may include telemetry or other types of sensors configured to detect, and/or receive, information (e.g., conditions associated with the devices). Sensors <NUM> may include sensors configured to sense conditions associated with CPUs, memory or other storage components, FPGAs, motherboards, baseboard management controllers, or the like. Sensors <NUM> may also include sensors configured to sense conditions associated with racks, chassis, fans, power supply units (PSUs), or the like. Sensors <NUM> may also include sensors configured to sense conditions associated with Network Interface Controllers (NICs), Top-of-Rack (TOR) switches, Middle-of-Rack (MOR) switches, routers, power distribution units (PDUs), rack level uninterrupted power supply (UPS) systems, or the like.

With continued reference to <FIG>, sensors <NUM> may be implemented in hardware, software, or a combination of hardware and software. Some sensors <NUM> may be implemented using a sensor API that may allow sensors <NUM> to receive information via the sensor API. Software configured to detect or listen to certain conditions or events may communicate via the sensor API any conditions associated with devices that are part of the harvesting of resources in a data center or another like systems. Remote sensors or other telemetry devices may be incorporated within the data centers to sense conditions associated with the components installed therein. Remote sensors or other telemetry may also be used to monitor other adverse signals in the data center. As an example, if fans that are cooling a rack stop working then that may be sensed by the sensors and reported to the deployment and monitoring functions. This type of monitoring may ensure that any impact on the harvesting of resources is detected, recorded, and corrected, as needed.

Still referring to <FIG>, database <NUM> may be used to store records related to the harvesting of unused resources, including policy records establishing which resources may be used or not used. The policy records may also be used to establish fairness-based policies to allow the harvesting of the resources in a manner that the tenants of the host servers are not unfairly impacted. In addition, database <NUM> may also store data used for generating reports related to the harvesting of the resources.

Network interfaces <NUM> may include communication interfaces, such as Ethernet, cellular radio, Bluetooth radio, UWB radio, or other types of wireless or wired communication interfaces. Although <FIG> shows computing platform <NUM> as including a certain number of components arranged and coupled in a certain way, it may include fewer or additional components arranged and coupled differently. In addition, the functionality associated with computing platform <NUM> may be distributed, as needed. Moreover, although <FIG> describes the access to the unused resources by VMs, other types of compute entities, such as containers, micro-VMs, microservices, unikernels for serverless functions, may access the unused resources associated with the host server in a like manner.

<FIG> shows a flowchart <NUM> of a method in accordance with one example. In this example, this method may be performed in a system including at least one host server and at least one interface card configured to interface with a network or a storage, where the at least one host server comprises a processor having a first instruction set architecture (ISA) (e.g., an x86-based processor) and the at least one interface card comprises a processor having a second ISA (e.g., an ARM®-based processor), different from the first ISA. As an example, this method may be performed in system environment <NUM> of <FIG> using system <NUM> of <FIG> or system <NUM> of <FIG>. Step <NUM> may include designating at least one type of resource, associated with the at least one host server, for harvesting by compute entities configured for execution using the processor having the second ISA. As an example, using system <NUM> of <FIG>, or system <NUM> of <FIG>, memory or I/O devices may be designated as the type of resources that could be harvested by compute entities being executed by the processor having the second ISA (e.g., an ARM®-based processor).

Step <NUM> may include in response to a request for accessing the at least one type of resource by a compute entity, executing on the processor having the second ISA, automatically allowing the compute entity to access the at least one type of resource associated with the at least one host server. As an example, using system <NUM> of <FIG>, or system <NUM> of <FIG>, the memory or I/O devices may be designated as the type of resources that could be harvested by compute entities being executed by the processor having the second ISA. Although <FIG> describes flow chart <NUM> as including a certain number of steps being executed in a certain order, the method of harvesting resources may include additional steps executed in a different order.

<FIG> shows another flowchart <NUM> of a method in accordance with one example. In this example, this method may be performed in a system including at least one host server and at least one interface card configured to interface with a network or a storage, where the at least one host server comprises a processor having a first instruction set architecture (ISA) (e.g., an x86-based processor) and the at least one interface card comprises a processor having a second ISA (e.g., an ARM®-based processor), different from the first ISA. As an example, this method may be performed in system environment <NUM> of <FIG> using system <NUM> of <FIG> or system <NUM> of <FIG>. Step <NUM> may include the at least one host server designating at least one type of resource, associated with the at least one host server for harvesting by compute entities configured for execution using the processor having the second ISA, where the host server is configured to execute virtual machines requiring execution by the processor having the first ISA. As an example, using system <NUM> of <FIG>, or system <NUM> of <FIG>, the at least one host server may designate memory or I/O devices as the type of resources that could be harvested by compute entities being executed by the processor having the second ISA (e.g., an ARM®-based processor).

Step <NUM> may include a first hypervisor associated with the at least one host server sharing control information with a second hypervisor associated with the at least one interface card to enable access to the portion of the host memory and the portion of the I/O device. As an example, using system <NUM> of <FIG>, system <NUM> of <FIG>, or system <NUM> of <FIG>, a first hypervisor (e.g., hypervisor <NUM>) associated with the at least one host server (host server <NUM>) may share control information with a second hypervisor (e.g., hypervisor <NUM>) associated with the at least one interface card (e.g., interface card <NUM>) to enable access to the portion of the host memory and the portion of the I/O device.

In conclusion, the present disclosure relates to a method in a system including at least one host server and at least one interface card configured to interface with a network or a storage, where the at least one host server comprises a processor having a first instruction set architecture (ISA) and the at least one interface card comprises a processor having a second ISA, different from the first ISA. The method may include designating at least one type of resource, associated with the at least one host server for harvesting by compute entities configured for execution using the processor having the second ISA, where the host server is configured to execute compute entities requiring execution by the processor having the first ISA. The method may further include in response to a request for accessing the at least one type of resource by a compute entity, executing on the processor having the second ISA, automatically allowing the compute entity to access the at least one type of resource associated with the at least one host server.

The first ISA may comprise a complex instruction set computer (CISC) instruction set architecture. The second ISA may comprise a reduced instruction set computer (RISC) instruction set architecture.

The at least one resource designated by the host server for harvesting by the virtual machines configured for execution using the processor having the second ISA may comprise a volatile memory or a non-volatile memory. The at least one resource designated by the host server for harvesting by the virtual machines configured for execution using the processor having the second ISA may comprise an input/output device.

The compute entity may include at least one of a virtual machine (VM), a micro-VM, a microservice, or a unikernel for serverless functions. The accessing the at least one type of resource by the compute entity may comprise performing address translation.

In another aspect, the present disclosure relates to a method in a system including at least one host server and at least one interface card configured to interface with a network or a storage, where the at least one host server comprises a processor having a first instruction set architecture (ISA) and the at least one interface card comprises a processor having a second ISA, different from the first ISA. The method may include the at least one host server designating at least one type of resource, associated with the at least one host server for harvesting by compute entities configured for execution using the processor having the second ISA, where the host server is configured to execute virtual machines requiring execution by the processor having the first ISA. The at least one type of resource includes at least one of a host memory and an input/output (I/O) device. The method may further include a first hypervisor associated with the at least one host server sharing control information with a second hypervisor associated with the at least one interface card to enable access to the portion of the host memory and the portion of the I/O device. The method may further include in response to a request for accessing the at least one type of resource by a compute entity, executing on the processor having the second ISA, automatically allowing the compute entity to access the at least one type of resource associated with the at least one host server.

The host memory may comprise a volatile memory or a non-volatile memory. The I/O device may comprise a storage device or a networking device.

The compute entity may include at least one of a virtual machine (VM), a micro-VM, a microservice, or a unikernel for serverless functions. The accessing the at least one type of resource by the compute entity may comprise performing address translation. The control information may include information concerning mapping of memory pages associated with the at least one host server.

In yet another aspect, the present disclosure relates to a distributed computing system including a host server comprising a processor having a first instruction set architecture (ISA), where the host server is configured to service compute entities corresponding to at least one tenant, and where each of the compute entities is required to execute using the processor having the second ISA. The distributed computing system may further include an interface card, coupled to the host server, comprising a processor having a second ISA. The distributed computing system may further include a system configured to: (<NUM>) allow designation of at least one type of resource, associated with the host server for harvesting by compute entities configured for execution using the processor having the second ISA, (<NUM>) allow sharing of control information between a first hypervisor associated with the host server and a second hypervisor with the interface card, and (<NUM>) in response to a request for accessing the at least one type of resource by a compute entity, executing on the processor having the second ISA, automatically allow the compute entity to access the at least one type of resource associated with the at least one host server.

The first ISA may comprise a complex instruction set computer (CISC) instruction set architecture and the second ISA may comprise a reduced instruction set computer (RISC) instruction set architecture. The at least one resource designated by the host server for harvesting by the virtual machines configured for execution using the processor having the second ISA may comprise a volatile memory, a non-volatile memory, or an input/output device.

The compute entity may comprise at least one of a virtual machine (VM), a micro-VM, a microservice, or a unikernel for serverless functions. The control information may include information concerning mapping of memory pages associated with the at least one host server.

It is to be understood that the methods, modules, and components depicted herein are merely exemplary. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc. In an abstract, but still definite sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or inter-medial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "coupled," to each other to achieve the desired functionality.

The functionality associated with some examples described in this disclosure can also include instructions stored in a non-transitory media. The term "non-transitory media" as used herein refers to any media storing data and/or instructions that cause a machine to operate in a specific manner. Exemplary non-transitory media include non-volatile media and/or volatile media. Non-volatile media include, for example, a hard disk, a solid state drive, a magnetic disk or tape, an optical disk or tape, a flash memory, an EPROM, NVRAM, PRAM, or other such media, or networked versions of such media. Volatile media include, for example, dynamic memory such as DRAM, SRAM, a cache, or other such media. Non-transitory media is distinct from, but can be used in conjunction with transmission media. Transmission media is used for transferring data and/or instruction to or from a machine. Exemplary transmission media, include coaxial cables, fiber-optic cables, copper wires, and wireless media, such as radio waves.

Furthermore, those skilled in the art will recognize that boundaries between the functionality of the above described operations are merely illustrative. The functionality of multiple operations may be combined into a single operation, and/or the functionality of a single operation may be distributed in additional operations. Moreover, alternative embodiments may include multiple instances of a particular operation, and the order of operations may be altered in various other embodiments.

Although the disclosure provides specific examples, various modifications and changes can be made without departing from the scope of the disclosure as set forth in the claims below. Any benefits, advantages, or solutions to problems that are described herein with regard to a specific example are not intended to be construed as a critical, required, or essential feature or element of any or all the claims.

Claim 1:
A method in a system including at least one host server (<NUM>) and at least one interface card (<NUM>) configured to interface with a network or a storage, wherein the at least one host server (<NUM>) comprises a processor (<NUM>) having a first instruction set architecture, ISA, and the at least one interface card (<NUM>) comprises a processor (<NUM>) having a second ISA, the method comprising:
designating (<NUM>) at least one type of resource, associated with the at least one host server (<NUM>) for harvesting by compute entities (<NUM>, <NUM>, <NUM>), the compute entities (<NUM>, <NUM>, <NUM>) configured for execution using the processor (<NUM>) having the second ISA, wherein the at least one host server (<NUM>) is configured to execute compute entities (<NUM>, <NUM>, <NUM>) requiring execution by the processor (<NUM>) having the first ISA; and
in response to a request for accessing the at least one type of resource by a compute entity, executing (<NUM>) on the processor (<NUM>) having the second ISA, automatically allowing the compute entity to access the at least one type of resource associated with the at least one host server (<NUM>).