Optimized network device queue management for hybrid cloud networking workloads

A network device queue manager receives a request to execute a workload on a node of a cloud computing environment, where the cloud computing environment comprises a plurality of nodes; determines that the workload is to be executed by a dedicated processor resource; identifies a set of one or more shared processor resources associated with the node, wherein each shared processor resource of the set of shared processor resources processes device interrupts; selects a processor resource from the set of one or more shared processor resources to execute the first workload on the first node; bans the selected processor resource from processing device interrupts while executing the workload; and executes the workload with the selected processor resource.

TECHNICAL FIELD

The present disclosure is generally related to computer systems, and more particularly, to optimizing network device queue management for workloads in cloud computing systems.

BACKGROUND

Platform-as-a-Service (PaaS) system offerings can include software and/or hardware facilities for facilitating the execution of applications (web applications, mobile applications, etc.) in a cloud computing environment (the “cloud”). Cloud computing is a computing paradigm in which a user engages a “cloud provider” to execute a program on computer hardware owned and/or controlled by the cloud provider. A cloud provider can make virtual machines (VMs) hosted on its computer hardware available to customers for this purpose. The cloud provider can provide an interface that a user can use to requisition virtual machines and associated resources such as security policies, processors, storage, and network services, etc., as well as an interface to install and execute the user's applications and files on the virtual machines.

PaaS offerings can facilitate deployment of application workloads without the cost and complexity of buying and managing the underlying hardware and software and provisioning hosting capabilities, providing the facilities to support the complete life cycle of building and delivering application workloads and services entirely available from the Internet.

DETAILED DESCRIPTION

Described herein are methods and systems for optimizing network device queue management for workloads in a cloud computing environment. Cloud computing environments provide many advantages over locally owned computing systems. For example, cloud computing environments can optimize resources by sharing them across multiple users and multiple clients, thereby reducing costs otherwise dedicated to procuring and maintaining local hardware. Additionally, cloud computing environments provide improved scalability for clients. Instead of purchasing additional local computing resources, supporting more data storage and buying more software licenses to support growth in the business, users can rent more storage space, acquire more bandwidth and increase access to software programs which are controlled by a cloud computing provider. Moreover, cloud computing environments can include multiple nodes that can be provisioned to receive and execute executable workloads.

Each node in a cloud computing environment can be provisioned such that its processor resources (e.g., CPU resources) can be configured either to process or to ban device interrupts issued by the devices associated with that node, depending on the processing requirements for executable workloads. CPUs of a particular node can be configured as a “shared” processor resource (also referred to as “reserved” processor resources or CPUs) that can process executable workloads, operating system (OS) operations, device interrupts from hardware devices, or the like. Thus, executable workloads that are executed by shared CPUs can be interrupted if a higher priority OS task or device interrupt is issued to that CPU. Additionally, some CPUs of a node can be configured as “dedicated” processor resources (also referred to as “isolated” or “guaranteed” processor resources) that do not process device interrupts or OS tasks while executing a workload. This type of CPU provisioning can be utilized by workloads that request 100% CPU utilization without being interrupted by other tasks (e.g., OS or device interrupts). For example, some workloads can implement “user-level networking” functionality, which incorporates any needed networking operations within the user space of the workload, thus eliminating the need for system networking resources that would cause networking device interrupts. Workloads that are to be executed by dedicated CPUs can be referred to as “user-level”, “guaranteed”, “dedicated”, etc. workloads.

Cloud computing environments configured in this way, however, can present challenges with the management of processor resources executable workloads. Conventional systems often partition the CPUs of each node into static pools (e.g., non-modifiable groups)—one pool for shared CPUs and another pool for dedicated CPUs. Nodes configured in this way can provide the ability to handle guaranteed workloads, while at the same time provide the shared resources needed to handle OS and device interrupt related tasks. This, however, can result in reduced efficiency in environments with a large number of connected devices. If a node is configured with too few shared processor resources, the shared pool can be insufficient to handle the interrupt traffic produced by the node's devices during periods of heavy activity.

Some conventional cloud computing environments attempt to mitigate the risk of cascading disruptions by increasing the number of shared CPUs that are reserved for processing OS tasks and device interrupts. While this can mitigate problems with overloading interrupt handlers, this can lead to significant inefficiencies with respect to periods of lower interrupt activity. If a node is configured with too many shared processor resources that cannot be utilized for guaranteed workloads, periods of lower activity can result in shared resources remaining idle, wasting valuable processing power that could otherwise be used to execute guaranteed workloads.

Aspects of the present disclosure address the above noted and other deficiencies by implementing a network device queue manager (e.g., as a computer program or a computer program component) to facilitate optimized network device queue management for workloads in a cloud computing environment. The processor resources of a node can be initially configured as a single pool of shared CPUs. The network device queue manager can subsequently dynamically reconfigure CPUs from shared CPUs to dedicated CPUs based on received requests to execute guaranteed workloads. When a request is received to execute a workload that is to be executed by a dedicated CPU, the network device queue manager can identify an available shared CPU, and ban that CPU from processing device interrupts while the requested workload is executing. The network device queue manager can facilitate this by updating the pool of shared CPUs to exclude the CPU selected to execute the requested workload and reconfiguring each device associated with the node to send interrupts only to the updated pool of shared resources. Subsequently, the devices for that node should not send interrupts to the newly designated dedicated CPU.

Aspects of the present disclosure present advantages over conventional solutions to the issues noted above. First, the network device queue manager of the present disclosure is capable of dynamically managing the processor resource needs of all workloads for a node without the limitations of conventional static partitioning. By converting a CPU (or group of CPUs) from a shared resource to a dedicated resource to execute a particular workload and subsequently returning it back to the pool of shared resources, the network device queue manager can significantly improve the efficiency of processor resource utilization for the entire node. Additionally, eliminating the need for static processor partitioning can provide the ability for a cloud service provider to support hybrid networking workloads (e.g., supporting both user-level networking as well as kernel/OS networking) in the same cluster node. This, in turn can significantly improve the efficiency and cost-effectiveness of provisioned hardware resources both on particular nodes as well as across the cloud computing system overall.

FIG.1is a block diagram of a network architecture100in which implementations of the disclosure may operate. In some implementations, the network architecture100may be used in a containerized computing services platform. A containerized computing services platform may include a Platform-as-a-Service (PaaS) system, such as OpenShift® or Kubernetes®. The PaaS system provides resources and services (e.g., micro-services) for the development and execution of applications owned or managed by multiple users. A PaaS system provides a platform and environment that allow users to build applications and services in a clustered compute environment (the “cloud”) Although implementations of the disclosure are described in accordance with a certain type of system, this should not be considered as limiting the scope or usefulness of the features of the disclosure. For example, the features and techniques described herein can be used with other types of multi-tenant systems and/or containerized computing services platforms.

As shown inFIG.1, the network architecture100includes a cloud-computing environment130(also referred to herein as a cloud) that includes nodes111,112,121to execute applications and/or processes associated with the applications. A “node” providing computing functionality may provide the execution environment for an application of the PaaS system. In some implementations, the “node” may refer to a virtual machine (VM) that is hosted on a physical machine, such as host1110through host N120, implemented as part of the cloud130. For example, nodes111and112are hosted on physical machine of host1110in cloud130provided by cloud provider104. In some implementations, an environment other than a VM may be used to execute functionality of the PaaS applications. When nodes111,112,121are implemented as VMs, they may be executed by operating systems (OSs)115,125on each host machine110,120.

In some implementations, the host machines110,120are often located in a data center. Users can interact with applications executing on the cloud-based nodes111,112,121using client computer systems, such as clients160,170and180, via corresponding client software161,171and181. Client software161,171,181may include an application such as a web browser. In other implementations, the applications may be hosted directly on hosts 1 through N110,120without the use of VMs (e.g., a “bare metal” implementation), and in such an implementation, the hosts themselves are referred to as “nodes”.

Clients160,170, and180are connected to hosts110,120in cloud130and the cloud provider system104via a network102, which may be a private network (e.g., a local area network (LAN), a wide area network (WAN), intranet, or other similar private networks) or a public network (e.g., the Internet). Each client160,170,180may be a mobile device, a PDA, a laptop, a desktop computer, a tablet computing device, a server device, or any other computing device. Each host110,120may be a server computer system, a desktop computer or any other computing device. The cloud provider system104may include one or more machines such as server computers, desktop computers, etc.

In various implementations, developers, owners, and/or system administrators of the applications may maintain applications executing in cloud130by providing software development services, system administration services, or other related types of configuration services for associated nodes in cloud130. This can be accomplished by accessing cloud130using an application programmer interface (API) within the applicable cloud service provider system104. In some implementations, a developer, owner, or system administrator may access the cloud service provider system104from a client device (e.g., clients160,170, and180) that includes dedicated software to interact with various cloud components. Additionally, or alternatively, the cloud service provider system104may be accessed using a web-based or cloud-based application that executes on a separate computing device that communicates with a client device via network102.

In one implementation, the cloud provider system104is coupled to a cloud controller108via the network102. The cloud controller108may reside on one or more machines (e.g., server computers, desktop computers, etc.) and may manage the execution of applications in the cloud130. In some implementations, cloud controller108receives commands from containerized system controller140. In view of these commands, the cloud controller108provides data (e.g., such as pre-generated images) associated with different applications to the cloud provider system104. In some implementations, the data may be provided to the cloud provider104and stored in an image repository106, in an image repository (not shown) located on each host110,120, or in an image repository (not shown) located on each node111,112,121. This data may be used for the execution of applications for a containerized computing services platform managed by the containerized system controller140.

In various implementations, the data can be used for execution of one or more executable workloads151,152,153. In various implementations, a workload151,152,153can be a pod, a container, a standalone application to be executed in a pod, container, or virtual machine (VM), a VM that itself hosts one or more applications, a container process that itself hosts one or more applications or VMs, or any other entity or executable component that can be scheduled by the cloud computing system scheduler in cloud controller108or containerized system controller140.

In some implementations, the pods can be a group of one or more containers that are deployed together on the same node111,112,121, and are the smallest compute unit that can be defined, deployed, and managed in the containerized computing service environment. Each pod is allocated its own internal IP address, with containers within pods being able to share local storage and networking. Pods can have a lifecycle that is defined and can run on a node111,112,121until the pod's containers exit or they are removed for some other reason.

Containers can include application images built from pre-existing application components and source code of users managing the application. An image may refer to data representing executables and files of the application used to deploy functionality for a runtime instance of the application. In some implementations, the application images can be built using various types of containerization technologies (e.g., Docker™). An image build system (not pictured) can generate an application image for an application by combining a preexisting ready-to-run application image corresponding to core functional components of the application (e.g., a web framework, database, etc.) with source code specific to the application provided by the user. The resulting application image may be pushed to image repository106for subsequent use in launching instances of the application images for execution in the PaaS system.

In various implementations, a container can be a secure process space on the nodes111,112,121to execute functionality of an application. In some implementations, a container is established at the nodes111,112,121and122with access to certain resources of the underlying node, including memory and storage. In one implementation, the containers may be established using the Linux Containers (LXC) method. In further implementations, containers may also be established using cgroups, SELinux™, and kernel namespaces, to name a few examples.

In some implementations, each node111,112,121can include a network device queue manager142to optimize the network device queue management associated with the applicable node. Network device queue manager142can configure the attributes of its associated node111,112,121such that each processor resource (e.g., processor, CPU, etc.) for that node is initially configured as a shared processor resource. A shared processor resource is a processor, CPU, etc. associated with the node that can process both executable workloads as well as device interrupts, operating system functions, etc. Thus, a shared processor resource is a non-dedicated resource that is interruptible by higher priority tasks.

When a request is received to execute a workload151,152,153that is to be executed by a dedicated processor resource, network device queue manager can convert one or more of the node's shared processor resources to a dedicated processor resource for executing that workload. A dedicated processor resource is a processor, CPU, etc. associated with the node that is dedicated to executing an executable workload without interruption. Thus, a dedicated processor resource should not be interrupted by operating system tasks, device interrupts, etc. Dedicated processor resources can also be referred to herein as “isolated” processor resources/processors/CPUs, etc., or “guaranteed” “processor resources/processors/CPUs, etc.

Network device queue manager142can receive a request to execute a workload in cloud130. In some implementations, the request may be received from one of clients160,170,180. Alternatively, the request may be received from a scheduling component of the cloud controller108or containerized system controller140. The request may be associated with a new workload to be executed within cloud130. Alternatively, the request may be responsive to identifying a currently executing workload that may be selected for migration to another node.

As will be discussed in further detail below, network device queue manager142can determine whether the requested workload is to be executed by a dedicated processing resource (e.g., a dedicated CPU) that does not process device interrupts. As described in further detail below, workloads that are to be executed by dedicated CPUs can be referred to as “dedicated” workloads (e.g., workloads that need “dedicated” CPUs), “user-level” workloads (e.g., workloads that provide their own networking capabilities, and thus do not make use of operating system networking resources), “guaranteed” workloads (e.g., workloads that need guaranteed uninterrupted CPU utilization), or the like. If network device queue manager142determines that the requested workload is to be executed by a dedicated CPU, network device queue manager142can identify the pool of shared processor resources (e.g., shared CPUs) associated with the node that are configured to process device interrupts, and select one or more shared processor resources (depending on the needs of the requested workload) to executed the requested workload.

Once a shared processor resource has been selected from the node's pool of processor resources, network device queue manager142can ban the selected processor resource from processing device interrupts while executing the requested workload. As described in further detail below, the “banning” process can convert the selected shared processor resource(s) to dedicated processor resource(s) for the duration of the execution of the selected workflow. In various implementations, network device queue manager142can complete this process by reconfiguring all devices for that node to send interrupts only to those processor resources in the pool of shared processor resources. Thus, the devices on that node should not send any interrupts to the dedicated CPUs that have been allocated for executing the “user-level”, “guaranteed”, etc. workloads. Network device queue manager142can subsequently execute the requested workload on the converted dedicated processor(s).

When the workload completes execution, network device queue manager142can reverse the process by converting the any dedicated CPUs used by that workload back to shared CPUs. Network device queue manager142can return those CPUs to the pool of shared CPUs and reconfigure the devices associated with the node to resume sending device interrupts to those CPUs. In some implementations, when another workload has been staged for execution that has requested a dedicated CPU, this reconversion process can be bypassed to save processing resources. Thus, a dedicated CPU can be provisioned to a new workload that has requested a dedicated CPU without first returning it to the pool of shared CPUs.

While aspects of the present disclosure describe the network device queue manager142as implemented in a PaaS environment, it should be noted that in other implementations, the security profile manager can also be implemented in an Infrastructure-as-a-Service (Iaas) environment, such as such as Red Hat OpenStack®. Additionally, while for simplicity of illustration,FIG.1depicts a single cloud130, aspects of the present disclosure can be implemented to manage workloads across multiple clouds130. In such instances the network device queue manager142can manage device queues within hybrid cloud environments, multi-cluster cloud environments, or the like. Network device queue manager142is described in further detail below with respect toFIGS.2-4.

FIG.2depicts a block diagram illustrating an example of a network device queue manager210for facilitating optimized network device queue management for hybrid cloud networking workloads in a cloud computing environment. In some implementations, network device queue manager210may correspond to network device queue manager142ofFIG.1. As shown inFIG.2, network device queue manager210may be a component of a computing apparatus200that includes a processing device205, operatively coupled to a memory201, to execute workload resource manager210. In some implementations, processing device205and memory201may correspond to processing device502and main memory504respectively as described below with respect toFIG.5.

Network device queue manager210may include request receiver211, processor resource determiner212, shared processor resource identifier213, shared processor resource selector214, interrupt banning module215, interrupt enabling module216, workload execution module217, and scheduler notification module218. Alternatively, the functionality of one or more of request receiver211, processor resource determiner212, shared processor resource identifier213, shared processor resource selector214, interrupt banning module215, interrupt enabling module216, workload execution module217, and scheduler notification module218may be combined into a single module or divided into multiple sub-modules.

Request receiver211is responsible for receiving a request to execute a workload on a node of a cloud computing environment. As noted above, in some implementations, the cloud computing environment can include multiple nodes, where nodes can include pods, and/or containers that can be used to execute a process (or processes) within the environment. In various implementations, the workload process can be a pod, a container, a standalone application to be executed in a container, pod, or virtual machine (VM), a virtual machine that itself hosts one or more applications, a container process that itself hosts one or more applications or VMs, or any other entity or component that can be scheduled by the cloud computing system scheduler. Cloud computing environments configured in such a manner can be an OpenShift® based environment, a Kubernetes® based environment, or the like. In some implementations, the cloud computing environment can be a hybrid cloud or multi-cluster cloud environment made up of multiple clouds of the same or different cloud providers (e.g., one cloud may be an OpenShift® cloud, a second cloud could be a Kubernetes® cloud, a third cloud could be an Amazon Web Services® (AWS) cloud, etc.).

In various implementations, request receiver module211can receive the request to execute the workload from a client device (e.g., client devices160,170,180ofFIG.1). The request may be received from a developer or system administrator of the cloud computing environment to execute an application process. Alternatively, the request may be received from an end user accessing a cloud computing service provided by the environment. In other implementations, the request can be received from a scheduler component of the cloud computing environment (e.g., a component of cloud controller108or containerized system controller140ofFIG.1) to execute a workload on a particular node.

In some implementations, request receiver module211can receive additional preference information associated with the workload process to be used in selecting a processor resource on the node to execute the workload. In some implementations, the request can specify that the associated workload is a “user-level”, “guaranteed” workload that is to be executed by a CPU that will not handle device interrupts (e.g., an “isolated”, “dedicated”, or “guaranteed” CPU). In other implementations, the request can include configuration information associated with the requested workload that indicates that the workload is to be executed by a dedicated processor resource. For example, the request can include configuration information that indicates that the requested workload will perform its own networking and should not be interrupted by device interrupts. In instances where configuration information is received with the request, this information can be stored for later use by other components of network device queue manager210(e.g., as workload configuration data202).

Processor resource determiner212is responsible for determining whether the workload associated with the received request is to be executed by a dedicated processor resource that does not process device interrupts (e.g., an “isolated”, “dedicated”, or “guaranteed” CPU). In some implementations, processor resource determiner212can make this determination in view of information received with the request. For example, as noted above, the request can specify whether the workload is to be executed by a dedicated processor resource. Alternatively, processor resource determiner212can make this determination using configuration information associated with the requested workload (e.g., workload configuration data202). In some implementations, responsive to determining that the workload is to be executed by a dedicated processor resource, processor resource determiner212can add an annotation (e.g., a flag, attribute, etc.) to the workload configuration associated with the workload to indicate this determination. For example, processor resource determiner212can add configuration data to workload configuration data202associated with the requested workload to indicate that the workload is a “user-level” or “guaranteed” workload that is to be executed by a CPU that does not process device interrupts.

Shared processor resource identifier213is responsible for identifying a set shared processor resources associated with the node. In various implementations, each shared processor resource of the set of shared processor resources can process device interrupts. In other words, none of the shared processor resources (e.g., none of the “non-isolated” CPUs) has been allocated to a “user-level” or “guaranteed” workload. In some implementations, shared processor resource identifier213can identify all shared processor resources for a node, whether they are associated with scheduled tasks or not. In other instances, shared processor resource identifier213can identify those shared processor resources that have not been scheduled to perform any other tasks (e.g., those that are idle and/or not associated with a scheduled task).

In some implementations, shared processor resource identifier213can make its determinations in view of a minimum number of processor resources needed by the node to provide operational effectiveness. In other words, in determining whether there are any available processing resources on the node to allocate to a workload in need of dedicated processor resources, shared processor resource identifier213can use as a factor the number of processors that should remain shared resources (e.g., and not assigned to workloads that need dedicated processor resources). In such instances, shared processor resource identifier213can determine the number of shared processor resources in the group of identified shared processor resources. Subsequently, shared processor resource identifier213can determine if the number of shared processor resources satisfies a low threshold number. For example, if the node should have at least three shared processors to handle device interrupts and operating system operations for that node, the threshold could be set to three. If the number of available shared processor resources for that node falls to three, then this would satisfy the low threshold value.

Responsive to determining that the number of shared processor resources satisfies the low threshold number, shared processor resource identifier213can send an indication to a scheduler component of the cloud computing environment to cause that component to reschedule the workload on a different node in the cloud computing environment that has additional processing resources to allocate to the workload. To continue the above example, if the threshold is set to three processor resources, and the current number in the identified group falls to three, shared processor resource identifier213can invoke scheduler notification module218to notify the scheduler for the cloud computing environment to reschedule the workload on a different node.

Shared processor resource selector214is responsible for selecting a processor resource from the set of shared processor resources on that node to execute the first workload. In some implementations, shared processor resource selector214can make this selection randomly (or pseudo-randomly). Alternatively, shared processor resource selector214can make the selection in a round robin fashion based on the number of processors associated with the node. In other implementations, shared processor resource selector214can select a processor resource that has not been recently selected to execute a workload needing a dedicated processing resource (e.g., another “user-level”, or “guaranteed” workload). In other implementations, shared processor resource selector214can select a processor resource that has recently been selected to execute a “user-level” or “guaranteed” workload. In these latter instances, some components of network device queue manager210can be bypassed as will be discussed below (e.g., interrupt banning module215).

In some implementations, once a processor resource (or multiple processor resources) has been selected to execute the requested workload, shared processor resource selector214can add an annotation to configuration data associated with the node's processors (e.g., processor configuration data203) that indicates whether each processor is assigned to a “user-level” or “guaranteed” workload. For example, processors that have been assigned to such workloads can be designated as “isolated”, “dedicated”, “guaranteed”, or the like. Similarly, processors that remain shared processor resources can be designated as “non-isolated”, “non-dedicated”, “non-guaranteed”, “shared”, or the like. As shared processor resource selector214makes its selection(s), it can additionally update configuration data that tracks the number of processors in each category. This number can be used by subsequent executions of shared processor resource identifier214to determine whether the number of available shared processor resources meets any low threshold number as described above.

Interrupt banning module215is responsible for banning the selected processor resource from processing device interrupts while executing the workload. As noted above, “banning” refers to the process of systematically preventing a shared processing resource from processing device interrupts issued by any device associated with the node. In various implementations, interrupt banning module215can ban the selected processor from processing device interrupts by converting that selected processor resource to a dedicated processor resource while executing the received workload.

In some implementations, interrupt banning module215can perform this operation by removing from the set of shared processors the processor selected by shared processor resource selector214. In some instances, interrupt banning module215can modify the appropriate counters that track the number of shared processors in the pool of shared processing resources as well as the number of dedicated processors that have been assigned “user-level” or “guaranteed” workloads. Subsequently, interrupt banning module215can then identify the devices associated with the node and reconfigure each of them to send interrupts only to the updated set of shared processor resources and not to any of the dedicated processor resources (e.g., the processors that are not in the set of shared processor resources).

In various implementations, when a node is initiated in a cloud computing environment, the initiation process configures the interrupt queues for each device to direct that device to the particular processor to which it can send interrupts. In such instances interrupt banning module215can re-execute that process to perform the device reconfiguration each time a processor resource is converted from a shared processor to a dedicated processor. Similarly, as described below, that process can be re-executed to reconfigure the devices each time a processor resource is converted from a dedicated processor back to a shared processor. In some implementations, as a part of the re-configuration process, interrupt banning module215can set the interrupt queue count for each device associated with the node to the total number of processor resources in the node minus the number of dedicated processor resources. Thus, the interrupt queue count for each device should represent the total number of shared processor resources that can process device interrupts.

As noted above, in some implementations, a subsequently received request to execute another workload using a dedicated processor resource can be assigned a dedicated processor that has recently completed executing a previously received “user-level” workload. In such instances, rather than identify a shared resource that is to be converted to a dedicated resource, network device queue manager can re-provision the dedicated processor resource to the newly received workload. In such instances, interrupt banning module215can be bypassed since the processor has already been converted to a dedicated processor, thus eliminating the need for reconfiguring the devices to exclude it from receiving device interrupts.

Workload execution module217is responsible for executing the workload using the assigned dedicated processor resource(s). Once the workload has completed execution, workload execution module217can invoke interrupt enabling module216to convert the dedicated processor resource back to a shared processor resource. In some implementations, as noted above, the dedicated processor resource assigned to that workload can be allocated to a newly received workload that is to be executed by a dedicated processor resource. In these instances, both interrupt enabling module216as well as interrupt banning module215can be bypassed since the processor has already been converted to a dedicated processor, so two device reconfiguration cycles can be eliminated to reduce additional processing costs.

Interrupt enabling module216is responsible for converting the dedicated processor resource back to a shared processor resource that can process device interrupts. In various implementations, interrupt enabling module216can be invoked responsive to determining that a workload has completed executing. Alternatively, interrupt enabling module216can be invoked if the applicable dedicated processor has not be reassigned to another workload, thus eliminating the present need to re-enable interrupts for that processor.

In instances where the dedicated processor is to be reconverted back to a shared processor, interrupt enabling module216can update the processor configuration data203to remove the applicable processor(s) to from the set of dedicated processors and add the applicable processor(s) to the set of shared processor resources. Similarly, interrupt enabling module216can determine the number of processor resources that are to be reconverted, adding that number to the total number of shared processor resources, and subtracting that number from the total number of dedicated processor resources. Subsequently, interrupt enabling module216can perform the device reconfiguration process described above to configure each of the node's devices to send interrupts only to the newly updated set of shared processor resources.

Scheduler notification module218is responsible for notifying the scheduler for the cloud computing environment to reschedule a workload on a different node. As noted above, scheduler notification module218can be invoked by shared processor resource identifier213to cause a requested workload to be scheduled on a different node if the currently selected node does not have the available processor resources to allow for converting a shared processor resource to a dedicated processor resource to satisfy the request.

FIGS.3A-3Cillustrate an example of optimized network device queue management for hybrid cloud networking workloads on a node300of a cloud computing environment. As shown inFIG.3A, a network device queue manager142receives a request to execute workload310on node300. As described above with respect toFIG.2, network device queue manager142can determine that workload310is a “guaranteed” or “user-level” workload that is to be executed by a “dedicated” or “isolated” CPU that does not process device interrupts. Also as described above, network device queue manager142can identify a set of shared processor resources associated with node300(e.g., shared CPUs320), where each of those processor resources processes device interrupts. As shown, devices341,342,343are hardware devices (e.g., networking devices, etc.) associated with node300that are each configured to send interrupts (depicted by interrupts350) to all CPUs (CPUs321-324) in the group of shared CPUs320.

Subsequently, network device queue manager142can select one (or more) of the shared CPUs320to execute workload310. As shown by operation361ofFIG.3A, network device queue manager142can select shared CPU324to execute workload310since there are no available dedicated CPUs already provisioned for that node to ban device interrupts.

As shown inFIG.3B, network device queue manager142can ban CPU324from processing device interrupts issued by devices341,342,343by dynamically converting CPU324from a shared CPU to a dedicated CPU. Network device queue manager142can remove CPU324from the set of shared CPUs320and add it to the set of dedicated CPUs325(illustrated by operation362). Additionally, network device queue manager142can reconfigure each of devices341,342,343to modify the interrupt queues such that the devices send device interrupts to the modified group of shared CPUs320(e.g., CPUs321,323,323) and not to CPU324(illustrated by the updated interrupts351). Subsequently, network device queue manager142can initiate execution of workload310using the selected CPU324.

As shown inFIG.3C, network device queue manager142return the selected CPU from the dedicated CPU pool back to the shared CPU pool320when workload310completes execution. As shown, network device queue manager142can convert dedicated CPU324back to shared CPU324by adding CPU324back to the pool of shared CPUs320(operation364). Network device queue manager142can additionally identify the devices for node300and again reconfigure each of devices341,342,343to modify the interrupt queues such that the devices send device interrupts to the modified group of shared CPUs320(e.g., CPUs321,322,322, and again324), which is illustrated by the updated interrupts352). The above process can be repeated for any additional workloads received by network device queue manager142that are to be executed by a dedicated CPU resource.

It should be noted that whileFIGS.3A-3Cillustrate a particular example of network device queue management based on a particular set of CPUs and devices, in other implementations, aspects of the present disclosure can be applied to nodes with more or fewer CPUs and/or devices.

FIG.4depicts a flow diagram of an example method400for facilitating optimized network device queue management for hybrid cloud networking workloads in a cloud computing environment. The method may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), computer readable instructions (run on a general purpose computer system or a dedicated machine), or a combination of both. In an illustrative example, method400may be performed by network device queue manager142inFIG.1. Alternatively, some or all of method400might be performed by another module or machine. It should be noted that blocks depicted inFIG.4could be performed simultaneously or in a different order than that depicted.

At block405, processing logic receives a request to execute a workload on a node of a cloud computing environment, wherein the cloud computing environment comprises a plurality nodes. At block410, processing logic determines that the workload is to be executed by a processor resource that is dedicated to execute the workload and should not process device interrupts. At block415, processing logic identifies a set of one or more shared processor resources associated with the node, where each shared processor resource of the set of shared processor resources processes device interrupts. At block420, processing logic selects a processor resource from the set of one or more shared processor resources to execute the first workload on the first node. At block425, processing logic bans the selected processor resource from processing device interrupts while executing the workload. At block430, processing logic executes the workload with the selected processor resource.

FIG.5depicts an example computer system500which can perform any one or more of the methods described herein. In one example, computer system500may correspond to computer system100ofFIG.1. The computer system may be connected (e.g., networked) to other computer systems in a LAN, an intranet, an extranet, or the Internet. The computer system may operate in the capacity of a server in a client-server network environment. The computer system may be a personal computer (PC), a set-top box (STB), a server, a network router, switch or bridge, or any device capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that device. Further, while a single computer system is illustrated, the term “computer” shall also be taken to include any collection of computers that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein.

The exemplary computer system500includes a processing device502, a main memory504(e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM)), a static memory506(e.g., flash memory, static random access memory (SRAM)), and a data storage device516, which communicate with each other via a bus508.

The computer system500may further include a network interface device522. The computer system500also may include a video display unit510(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device512(e.g., a keyboard), a cursor control device514(e.g., a mouse), and a signal generation device520(e.g., a speaker). In one illustrative example, the video display unit510, the alphanumeric input device512, and the cursor control device514may be combined into a single component or device (e.g., an LCD touch screen).

The data storage device516may include a non-transitory computer-readable medium524on which may store instructions526that include network device queue manager142(e.g., corresponding to the method ofFIG.4, etc.) embodying any one or more of the methodologies or functions described herein. Network device queue manager142may also reside, completely or at least partially, within the main memory504and/or within the processing device502during execution thereof by the computer system500, the main memory504and the processing device502also constituting computer-readable media. Network device queue manager142may further be transmitted or received over a network via the network interface device522.

Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “receiving,” “determining,” “executing,” “identifying,” “selecting,” “banning”, or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Aspects of the disclosure presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the specified method steps. The structure for a variety of these systems will appear as set forth in the description below. In addition, aspects of the present disclosure are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure as described herein.