Patent Grant
11842216
This disclosure relates to devices for processing stream data, for example, in the fields of networking and storage.
Conventional computing devices typically include components such as a central processing unit (CPU), a graphics processing unit (GPU), random access memory, storage, and a network interface card (NIC), such as an Ethernet interface, to connect the computing device to a network. Typical computing devices are processor centric such that overall computing responsibility and control is centralized with the CPU. As such, the CPU performs processing tasks, memory management tasks such as shifting data between local caches within the CPU, the random access memory, and the storage, and networking tasks such as constructing and maintaining networking stacks, and sending and receiving data from external devices or networks. Furthermore, the CPU is also tasked with handling interrupts, e.g., from user interface devices. Demands placed on the CPU have continued to increase over time, although performance improvements in development of new CPUs have decreased over time. General purpose CPUs are normally not designed for high-capacity network and storage workloads, which are typically packetized. In general, CPUs are relatively poor at performing stream data processing, because such traffic is fragmented in time and does not cache well. Nevertheless, server devices typically use CPUs to process stream data.
In general, this disclosure describes a new processing architecture that utilizes a data processing unit (DPU). Unlike conventional compute models that are centered around a central processing unit (CPU), example implementations described herein leverage a DPU that is specially designed and optimized for a data-centric computing model in which the data processing tasks are centered around, and the primary responsibility of, the DPU. For example, various data processing tasks, such as networking, security, storage, and analytics, as well as related work acceleration, distribution and scheduling, and other such tasks are the domain of the DPU. The DPU may be viewed as a highly programmable, high-performance input/output (I/O) and data-processing hub designed to aggregate and process network and storage I/O to and from multiple other components and/or devices. This frees resources of the CPU, if present, for computing-intensive tasks.
The highly programmable DPU comprises a network interface to connect to a network to send and receive stream data units (e.g., data packets), one or more host interfaces to connect to one or more application processors (e.g., a CPU) or storage devices to send and receive stream data units, and a multi-core processor with two or more of the processing cores executing a run-to-completion data plane operating system on which a software function is invoked for processing one or more of the stream data units, and with one or more of the processing cores executing a multi-tasking control plane operating system. The data plane operating system comprises a low level, run-to-completion operating system running on bare metal of the DPU that is configured to support software functions for performing data processing tasks. In some examples, the data plane operating system is also configured to support a control plane software stack that includes the multi-tasking control plane operating system. The DPU utilizes fine-grain work units, work unit queues, and a queue manager executed on the data plane operating system of each processing core to serialize packet processing such that data packets of a same packet flow are processed by a same processing core. In this way, the DPU is capable of processing any type of packet flow with fine granularity between processing cores and low processing overhead.
In one example, this disclosure is directed to a DPU integrated circuit comprising a network interface configured to send and receive stream data units with a network; a host interface configured to send and receive stream data units with an application processor or a storage device; a plurality of programmable processing cores; a run-to-completion data plane operating system executing on two or more of the plurality of programmable processing cores; a run-to-completion software function invoked on the data plane operating system on one of the plurality of programmable processing cores to process a work unit, wherein the work unit is associated with one or more of the stream data units, and wherein the work unit specifies the software function for processing the one or more of the stream data units and further specifies the one of the plurality of programmable processing cores for executing the software function; and a multi-tasking control plane operating system executing on one or more of the plurality of programmable processing cores.
In another example, this disclosure is directed to a system comprising a network, at least one of an application processor or a storage device, and a DPU integrated circuit. The DPU integrated circuit comprises a network interface configured to send and receive stream data units with the network; a host interface configured to send and receive stream data units with the at least one of the application processor or the storage device; a plurality of programmable processing cores; a run-to-completion data plane operating system executing on two or more of the plurality of programmable processing cores; a run-to-completion software function invoked on the data plane operating system on one of the plurality of programmable processing cores to process a work unit, wherein the work unit is associated with one or more of the stream data units, and wherein the work unit specifies the software function for processing the one or more of the stream data units and further specifies the one of the plurality of programmable processing cores for executing the software function; and a multi-tasking control plane operating system executing on one or more of the plurality of programmable processing cores.
The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.
In some examples, data center 10 may represent one of many geographically distributed network data centers. In the example of
This disclosure describes a new processing architecture in which a data processing unit (DPU) is utilized within one or more nodes. Unlike conventional compute models that are centered around a central processing unit (CPU), example implementations described herein leverage a DPU that is specially designed and optimized for a data-centric computing model in which the data processing tasks are centered around, and the primary responsibility of the DPU. The DPU may be viewed as a highly programmable, high-performance input/output (I/O) and data-processing hub designed to aggregate and process network and storage I/O to and from multiple other components and/or devices.
In accordance with the techniques of this disclosure, the highly programmable DPU comprises a network interface (e.g., Ethernet) to connect to a network to send and receive stream data units (e.g., data packets), one or more host interfaces (e.g., Peripheral Component Interconnect-Express (PCI-e)) to connect to one or more application processors (e.g., a CPU or a graphics processing unit (GPU)) or storage devices (e.g., solid state drives (SSDs)) to send and receive stream data units, and a multi-core processor with two or more of the processing cores executing a run-to-completion data plane operating system on which a software function is invoked for processing one or more of the stream data units, and with one or more of the processing cores executing a multi-tasking control plane operating system. The data plane operating system comprises a low level, run-to-completion operating system running on bare metal of the DPU that is configured to support software functions for performing data processing tasks. In some examples, the data plane operating system is also configured to support a control plane software stack that includes the multi-tasking control plane operating system (e.g., Linux). The DPU utilizes fine-grain work units, work unit queues, and a queue manager executed on the data plane operating system to serialize packet processing such that data packets of a same packet flow are processed by a same processing core. In this way, the DPU is capable of processing any type of packet flow with fine granularity between processing cores and low processing overhead.
In the illustrated example of
In accordance with the techniques described in this disclosure, one or more of the devices held in CPU rack 20, GPU rack 22, and/or DPU rack 24 may include DPUs. These DPUs, for example, may be responsible for various data processing tasks, such as networking, security, storage, and analytics, as well as related work acceleration, distribution and scheduling, and other such tasks. In some cases, the DPUs may be used in conjunction with application processors (e.g., a separate processing device, server, storage device or even a local CPU and/or local graphics processing unit (GPU) of the compute node hosting the DPU) to offload any data-processing intensive tasks and free the application processors for computing-intensive tasks. In other cases, where control plane tasks are relatively minor compared to the data-processing intensive tasks, the DPUs may take the place of the application processors.
For example, as further explained below, CPU rack 20 hosts a number of CPU blades 21 or other compute nodes that are designed for providing a high-speed execution environment. That is, each CPU blade may contain a number of multi-core processors specially tailored to provide high-performance application execution. Similarly, GPU rack 22 may host a number of GPU blades 23 or other compute nodes that are designed to operate under the direction of a CPU or a DPU for performing complex mathematical and graphical operations better suited for GPUs. SSD rack 26 may host a number of SSD blades 27 or other storage nodes that contain permanent storage devices designed for storage and retrieval of data.
In general, in accordance with the techniques described herein, various compute nodes within data center 10, such as any of CPU blades 21, GPU blades 23, and DPU blades 25, may include DPUs to perform data centric tasks within data center 10. In addition, various storage nodes within data center 10, such as any of SSD blades 27, may interact with DPUs within CPU blades 21, GPU blades 23, or DPU blades 25 to store data for the data centric tasks performed by the DPUs. As described herein, the DPU is optimized to perform input and output (I/O) tasks, such as storage and retrieval of data to and from storage devices (such as SSDs), networking, and the like. For example, the DPU may be configured to execute a large number of data I/O processing tasks relative to a number of instructions that are processed. The DPU may support one or more host interfaces, such as PCI-e ports. The DPU may support one or more high-speed network interfaces, such as Ethernet ports, without the need for a separate network interface card (NIC), and may include programmable hardware specialized for network traffic. The DPU may be highly programmable such that the DPU may expose hardware primitives for selecting and programmatically configuring data processing operations. The DPU may be optimized for these processing tasks as well. For example, the DPU may include hardware implementations of high-performance data processing tasks, such as cryptography, compression (and decompression), regular expression processing, lookup engines, or the like.
In the example shown in
One or more of the devices in the different racks 20, 22, 24, or 26 may be configured to operate as storage systems and application servers for data center 10. For example, CPU rack 20 holds a plurality of CPU blades (“CPUs A-N”) 21 that each includes at least a CPU. One or more of CPU blades 21 may include a CPU, a DPU, and one or more storage devices, e.g., SSDs, communicatively coupled via PCI-e links or buses. In this implementation, the DPU is configured to retrieve data from the storage devices on behalf of the CPU, store data to the storage devices on behalf of the CPU, and retrieve data from network 7 and/or switch fabric 14 on behalf of the CPU. One or more of CPU blades 21 may also include a GPU communicatively coupled to at least the DPU. In this case, the DPU is also configured to send offloaded processing tasks (e.g., graphics intensive processing tasks, or other tasks that may benefit from the highly parallel processing nature of a graphics processing unit) to the GPU. An example implementation of one of CPU blades 21 is described in more detail below with respect to compute node 30A of
In some examples, at least some of CPU blades 21 may not include their own DPUs, but instead are communicatively coupled to a DPU on another one of CPU blades 21. In other words, one DPU may be configured to control I/O and other data processing tasks for two or more CPUs on different ones of CPU blades 21. In still other examples, at least some of CPU blades 21 may not include their own DPUs, but instead are communicatively coupled to a DPU on one of DPU blades 25 held in DPU rack 24.
As another example, GPU rack 22 holds a plurality of GPU blades (“GPUs A-M”) 23 that each includes at least a GPU. One or more of GPU blades 23 may include a GPU, a DPU, and one or more storage devices, e.g., SSDs, communicatively coupled via PCI-e links or buses. In this implementation, the DPU is configured to control input and output of data with network 7 and/or switch fabric 14, feed the data from at least one of network 7, switch fabric 14, or the storage devices to the GPU for processing, and control storage of the data with the storage devices. An example implementation of one of GPU blades 23 is described in more detail below with respect to compute node 30B of
In some examples, at least some of GPU blades 23 may not include their own DPUs, but instead are communicatively coupled to a DPU on another one of GPU blades 23. In other words, one DPU may be configured to control I/O tasks to feed data to two or more GPUs on different ones of GPU blades 23. In still other examples, at least some of GPU blades 23 may not include their own DPUs, but instead are communicatively coupled to a DPU on one of DPU blades 25 held in DPU rack 24.
As a further example, DPU rack 24 holds a plurality of DPU blades (“DPUs A-X”) 25 that each includes at least a DPU. One or more of DPU blades 25 may include a DPU and one or more storage devices, e.g., SSDs, communicatively coupled via PCI-e links or buses such that DPU blades 25 may alternatively be referred to as “storage blades.” In this implementation, the DPU is configured to control input and output of data with network 7 and/or switch fabric 14, perform programmable processing tasks on the data, and control storage of the data with the storage devices. An example implementation of one of DPU blades 25 is described in more detail below with respect to storage node 33 of
As illustrated in
In general, DPUs may be included on or communicatively coupled to any of CPU blades 21, GPU blades 23, DPU blades 25, and/or SSD blades 27 to provide computation services and storage facilities for applications and data associated with customers 11. In this way, the DPU may be viewed as a building block for building and scaling out data centers, such as data center 10.
In the illustrated example of
The DPUs or any of the devices within racks 20, 22, 24, and 26 that include at least one DPU may also be referred to as access nodes. In other words, the term DPU may be used herein interchangeably with the term access node. As access nodes, the DPUs may utilize switch fabric 14 to provide full mesh (any-to-any) interconnectivity such that any of the devices in racks 20, 22, 24, 26 may communicate stream data (e.g., data packets of a given packet flow) to any other of the devices using any of a number of parallel data paths within the data center 10. For example, the DPUs may be configured to spray individual packets for packet flows between the DPUs and across some or all of the multiple parallel data paths in the data center switch fabric 14 and reorder the packets for delivery to the destinations so as to provide full mesh connectivity.
Although racks 20, 22, 24, and 26 are described in
Additional example details of various example access nodes are described in U.S. Provisional Patent Application No. 62/559,021, filed Sep. 15, 2017, entitled “Access Node for Data Centers,”, the entire content of which is incorporated herein by reference. More details on data center network architectures and interconnected access nodes are available in U.S. patent application Ser. No. 15/939,227, filed Mar. 28, 2018, entitled “Non-Blocking Any-to-Any Data Center Network with Packet Spraying Over Multiple Alternate Data Paths,”, the entire content of which is incorporated herein by reference.
A new data transmission protocol referred to as a Fabric Control Protocol (FCP) may be used by the different operational networking components of any of the DPUs of the devices within racks 20, 22, 24, 26 to facilitate communication of data across switch fabric 14. FCP is an end-to-end admission control protocol in which, in one example, a sender explicitly requests a receiver with the intention to transfer a certain number of bytes of payload data. In response, the receiver issues a grant based on its buffer resources, QoS, and/or a measure of fabric congestion. In general, FCP enables spray of stream data units (e.g., data packets of a packet flow) to all paths between a source and a destination node, and may provide resilience against request/grant packet loss, adaptive and low latency fabric implementations, fault recovery, reduced or minimal protocol overhead cost, support for unsolicited packet transfer, support for FCP capable/incapable nodes to coexist, flow-aware fair bandwidth distribution, transmit buffer management through adaptive request window scaling, receive buffer occupancy based grant management, improved end to end QoS, security through encryption and end to end authentication and/or improved ECN marking support. More details on the FCP are available in U.S. Provisional Patent Application No. 62/566,060, filed Sep. 29, 2017, entitled “Fabric Control Protocol for Data Center Networks with Packet Spraying Over Multiple Alternate Data Paths,”, the entire content of which is incorporated herein by reference.
In the example of
In some examples, SDN controller 18 operates to configure the DPUs of the devices within racks 20, 22, 24, 26 to logically establish one or more virtual fabrics as overlay networks dynamically configured on top of the physical underlay network provided by switch fabric 14. For example, SDN controller 18 may learn and maintain knowledge of the DPUs and establish a communication control channel with each of the DPUs. SDN controller 18 uses its knowledge of the DPUs to define multiple sets (groups) of two of more DPUs to establish different virtual fabrics over switch fabric 14. More specifically, SDN controller 18 may use the communication control channels to notify each of the DPUs for a given set which other DPUs are included in the same set. In response, the DPUs dynamically setup FCP tunnels with the other DPUs included in the same set as a virtual fabric over switch fabric 14. In this way, SDN controller 18 defines the sets of DPUs for each of the virtual fabrics, and the DPUs are responsible for establishing the virtual fabrics. As such, underlay components of switch fabric 14 may be unware of virtual fabrics. In these examples, the DPUs interface with and utilize switch fabric 14 so as to provide full mesh (any-to-any) interconnectivity between DPUs of any given virtual fabric. In this way, the devices within racks 20, 22, 24, 26 connected to any of the DPUs forming a given one of virtual fabrics may communicate stream data units (e.g., data packets of a given packet flow) to any other of the devices within racks 20, 22, 24, 26 coupled to the DPUs for that virtual fabric using any of a number of parallel data paths within switch fabric 14 that interconnect the DPUs of that virtual fabric. More details of DPUs or access nodes operating to spray stream data units within and across virtual overlay networks are available in U.S. Provisional Patent Application No. 62/638,788, filed Mar. 5, 2018, entitled “Network Access Node Virtual Fabrics Configured Dynamically over an Underlay Network,”, the entire content of which is incorporated herein by reference.
Although not shown, data center 10 may also include, for example, one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices.
In the example of
DPU 32A may be configured according to the various techniques of this disclosure. DPU 32A is a highly programmable I/O processor with a plurality of processing cores (as discussed below, e.g., with respect to
In the example of
In general, software programs executable on CPU 34 can perform instructions to offload some or all data-intensive processing tasks associated with the software program to DPU 32A. Each of the processing cores of DPU 32A may be programmable using a high-level programming language, e.g., C, C++, or the like. In general, the various hardware implementations of processes provided by DPU 32A may be associated with software libraries in the high-level programming language that may be utilized to construct software applications for execution by CPU 34 that, by way of the host interfaces, invoke and leverage the functionality of DPU 32A. Thus, a programmer can write a software program in the programming language and use function or procedure calls associated with the hardware implementations of various processes of DPU 32A to perform these functions, and when CPU 34 executes the software program, CPU 34 offloads performance of these functions/procedures to DPU 32A.
Additionally, or alternatively, CPU 34 may offload other software procedures or functions to DPU 32A to be executed by processing cores of DPU 32A. Furthermore, CPU 34 may offload software procedures or functions to GPU 36 via DPU 32A (e.g., computer graphics processes). In this manner, DPU 32A represents a dynamically programmable processing unit that can execute software instructions, as well as provide hardware implementations of various procedures or functions for data-processing tasks, which may improve performance of these procedures or functions.
In the example of
DPU 32B may be configured according to the various techniques of this disclosure. DPU 32B may operate substantially similar to DPU 32A described above with respect to
In the example of
As an example, in the case of artificial intelligence (AI) processing, control plane functions include executing control tasks to instruct a GPU to perform certain types of computationally intensive processing, and executing I/O tasks to feed a large amount of data to the GPU for processing. In general, I/O processing tasks that control data movement between GPUs and storage devices are more important for facilitating AI processing than the relatively minor control tasks. Therefore, in the example of AI processing, it makes sense to use DPU 32B in place of a CPU. In the example of
As shown, in this example, storage node 33 may include at least one DPU and at least one storage device, e.g., SSD. As another example, with respect to
In the example of
DPU 32C may be configured according to the various techniques of this disclosure. DPU 32C may operate substantially similar to DPU 32A of
In the example of
Additional example details of various example DPUs are described in U.S. Provisional Patent Application No. 62/530,691, filed Jul. 10, 2017, entitled “Data Processing Unit for Computing Devices,”, the entire content of which is incorporated herein by reference.
Example hardware and software architecture of a DPU are described below with respect to
Stream processing is a specialized type of conventional general-purpose processing supporting specialized limitations with regard to both access and directionality. Processing typically only accesses a limited portion of the stream at any time, called a “window,” within which it may access random addresses. Objects outside of the window are not accessible through a streaming interface. In contrast, general purpose processing views the whole memory as randomly accessible at any time. In addition, stream processing generally progresses in one direction, called the forward direction. These characteristics make stream processing amenable to pipelining, as different processors within a DPU can safely access different windows within the stream.
As described herein, processing of stream information may be associated with a “work unit.” A work unit (WU) is a container that is associated with a stream state and used to describe (i.e. point to) data within a stream (stored in memory) along with any associated meta-data and operations to be performed on the data. Work units may dynamically originate within a peripheral unit of a DPU (e.g. injected by a networking unit, a host unit, or a storage device interface) or within a processor of the DPU in association with one or more streams of data, and terminate at another peripheral unit or another processor of the DPU. Stream processing is typically initiated as a result of receiving one or more work units associated with respective portions of the stream, e.g., one or more stream data units or data packets of a packet flow.
A work unit may represent a fixed length data structure including an action value and one or more arguments. In one example, a work unit includes four words, a first word having a value representing an action value and three additional words each representing an argument. The action value may be considered a work unit header containing information necessary for message delivery and information used for work unit execution. More specifically, the action value of a work unit specifies a software function (also referred to as an event handler or work unit (WU) handler) for processing the one or more stream data units associated with the work unit, and specifies source and destination processing core for executing the software function. The other arguments of the work unit data structure may include a frame argument having a value acting as a pointer to a continuation work unit to invoke a subsequent WU handler, a flow argument having a value acting as a pointer to state that is relevant to the WU handler, and a stream data unit argument having a value acting as a pointer to the associated stream data units.
A data structure referred to as a work unit (WU) stack may be used in the multi-core processor system of the DPU to more readily manage and utilize an event driven, run-to-completion programming model of an operating system executed by the DPU. The WU data structure is a building block in the WU stack and can readily be used to compose a processing pipeline and services execution in the multi-core processor system of the DPU. The WU stack structure carries state, memory, and other information in auxiliary variables external to the program stack for any given processor core.
More details on work units, work unit stacks, and stream processing by data processing units are available in U.S. Provisional Patent Application No. 62/589,427, filed Nov. 21, 2017, entitled “Work Unit Stack Data Structures in Multiple Core Processor System,”, and U.S. patent application Ser. No. 15/949,692, entitled “Efficient Work Unit Processing in a Multicore System,”, filed Apr. 10, 2018, the entire content of each of which is incorporated herein by reference.
DPU 60 is a highly programmable I/O processor with a plurality of processing cores (as discussed below, e.g., with respect to
The software function invoked to process the work unit may be one of a plurality of software functions for processing stream data included in a library 70 provided by data plane OS 62. In the illustrated example, library 70 includes network functions 72, storage functions 74, security functions 76, and analytics functions 78. Network functions 72 may, for example, include network I/O data processing functions related to Ethernet, network overlays, networking protocols, encryption, and firewalls. Storage functions 74 may, for example, include storage I/O data processing functions related to NVME (non-volatile memory express), compression, encryption, replication, erasure coding, and pooling. Security functions 76 may, for example, include security data processing functions related to encryption, regular expression processing, and hash processing. Analytics functions 78 may, for example, include analytical data processing functions related to a customizable pipeline of data transformations.
In general, data plane OS 62 is a low level, run-to-completion operating system running on bare metal of DPU 62 that runs hardware threads for data processing and manages work units. As described in more detail below, data plane OS 62 includes the logic of a queue manager to manage work unit interfaces, enqueue and dequeue work units from queues, and invoke a software function specified by a work unit on a processing core specified by the work unit. In the run-to-completion programming model, data plane OS 62 is configured to dequeue a work unit from a queue, process the work unit on the processing core, and return the results of processing the work unit to the queues.
DPU 60 also includes a multi-tasking control plane operating system executing on one or more of the plurality of processing cores. In some examples, the multi-tasking control plane operating system may comprise Linux, Unix, or a special-purpose operating system. In some examples, as illustrated in
In another example, instead of running on top of data plane OS 62, the multi-tasking control plane operating system may run on one or more independent processing cores that are dedicated to the control plane operating system and different than the processing cores executing data plane OS 62. In this example, if an independent processing core is dedicated to the control plane operating system at the hardware level, a hypervisor may not be included in the control plane software stack. Instead, the control plane software stack running on the independent processing core may include the multi-tasking control plane operating system and one or more control plane service agents executing on the control plane operating system.
CPU 90 is an application processor with one or more processing cores optimized for computing-intensive tasks. In the illustrated example of
In the illustrated example of
Data plane OS 62 of DPU 60 is configured to receive stream data units for processing on behalf of the application level software executing on hypervisor/OS 92 of CPU 90. In the example of packet processing, the stream data units may comprise data packets of packet flows. In this example, the received packet flows may include any of networking packet flows, storage packet flows, security packet flow, analytics packet flows, or any combination thereof. Data plane OS 62 executing on one of the processing cores of DPU 60 may receive each of the packet flows in the form of one or more work units from a networking unit, host unit, or another one of the processing cores (as discussed below, e.g., with respect to
In the case where the received packet flow is not recognized by data plane OS 62, e.g., the packet flow is not yet set up in the flow table, data plane OS 62 may send the packet flow through the slow path in control plane 66 for set up. Control plane service agents 84 executing on control plane OS 82 then determine that the packet flow is legitimate, and send an instruction to data plane OS 62 to set up the packet flow in the flow table.
Once the packet flow is set up by control plane service agents 84, data plane OS 62 may assign the packet flow to a particular processing core of DPU 60 that can do stream processing for the packet flow. As one example, data plane OS 62 may execute a queue manager configured to receive a work unit associated with one or more data packets of the packet flow, enqueue the work unit to a work unit queue associated with the processing core for the packet flow, dequeue the work unit from the work unit queues to the processing core, and invoke the software function specified by the work unit on the processing core for processing the work unit.
Data plane OS 62 also provides interfaces to one or more hardware accelerators of DPU 62 (as discussed below, e.g., with respect to
As described herein, the DPU utilizes fine-grain work units, work unit queues, and a queue manager executed on the data plane operating system of each processing core to serialize packet processing such that data packets of a same packet flow are processed by a same processing core. In this way, the DPU is capable of processing any type of packet flow with fine granularity between processing cores and low processing overhead. For comparison, other multi-core systems may communicate using shared memory and locking to ensure coherency in memory. The locking schemes may be an order of magnitude larger grain than the work unit scheme described herein. For example, the processing overhead associated with the work unit scheme is less than 100 clock cycles. Processing overhead may include the number of cycles to implement a work unit and the number of cycles to dequeue and deploy the work unit to a given processing core for processing. Serializing packet processing on the given run-to-completion hardware thread to maintain synchronization, as described herein, results in roughly the same overhead as the locking schemes used in conventional multi-core systems.
In the illustrated example of
DPU 130 also includes a networking unit 142, a coherent memory manager 144, a non-coherent memory manager 145, one or more host units 146, a plurality of accelerators 148A-148X (“accelerators 148”), a queue manager 150, and a plurality of work unit (WU) queues 152. Although not illustrated in
In this example, DPU 130 represents a high performance, hyper-converged network, storage, and data processor and input/output hub. For example, networking unit 142 may be configured to send and receive stream data units with one or more external devices, e.g., network devices. Networking unit 142 may perform network interface card functionality, packet switching, and the like, and may use large forwarding tables and offer programmability. Networking unit 142 may expose network interface (e.g., Ethernet) ports for connectivity to a network, such as network 7 and/or switch fabric 14 of
Each of accelerators 148 may be configured to perform acceleration for various data processing functions, such as lookups, matrix multiplication, cryptography, compression, regular expression processing, or the like. For example, accelerators 148 may comprise hardware implementations of lookup engines, matrix multipliers, cryptographic engines, compression engines, regular expression interpreters, or the like.
Queue manager 150 is configured to maintain and manipulate WU queues 152. At least one of WU queues 152 may be associated with each of cores 140 and configured to store a plurality of work units enqueued for processing on the respective one of the cores 140. In some examples, each of cores 140 may have a dedicated one of WU queues 152 that stores work units for processing by the respective one of cores 140. In other examples, each of cores 140 may have two or more dedicated WU queues 152 that store work units of different priorities for processing by the respective one of cores 140. As illustrated in
Data processing unit 130 may utilize two types of on-chip memory or memory devices, namely coherent cache memory and non-coherent buffer memory (not shown in
Cores 140 may comprise one or more of MIPS (microprocessor without interlocked pipeline stages) cores, ARM (advanced RISC (reduced instruction set computing) machine) cores, PowerPC (performance optimization with enhanced RISC-performance computing) cores, RISC-V (RISC five) cores, or complex instruction set computing (CISC or x86) cores. Each of cores 140 may be programmed to process one or more events or activities related to a given packet flow such as, for example, a networking packet flow, a storage packet flow, a security packet flow, or an analytics packet flow. Each of cores 140 may be programmable using a high-level programming language, e.g., C, C++, or the like.
In some examples, the plurality of cores 140 executes instructions for processing a plurality of events related to each data packet of a packet flow, received by networking unit 142 or host units 146, in a sequential manner in accordance with one or more work units associated with the data packets. As described above, work units are sets of data exchanged between cores 140 and networking unit 142 or host unit 146 where each work unit may represent one or more of the events related to a given data packet. More specifically, a work unit is associated with one or more data packets, and specifies a software function for processing the data packets and further specifies one of cores 140 for executing the software function.
In general, to process a work unit, the one of cores 140 specified by the work unit is configured to retrieve the data packets associated with the work unit from a memory, and execute the software function specified by the work unit to process the data packets. For example, the one of cores 140 may retrieve the data packets from the non-coherent memory buffer via non-coherent memory manager 145, and cache the data packets in the one of caches 141 within the respective one of cores 140.
In a more detailed example, receiving a work unit is signaled by receiving a message in a work unit receive queue (e.g., one of WU queues 152). Each of WU queues 152 is associated with one of cores 140 and is addressable in the header of the work unit message. Upon receipt of the work unit message from networking unit 142, one of host units 146, or another one of cores 140, queue manager 150 enqueues a work unit in the one of WU queues 152 associated with the one of cores 140 specified by the work unit. After queue manager 150 dequeues the work unit from the one of WU queues 152, queue manager 150 delivers the work unit to the one of cores 140. Queue manager 150 then invokes the software function specified by the work unit on the one of cores 140 for processing the work unit.
To process the work unit, the one of cores 140 receives the work unit from the one of WU queues 152. The one of cores 140 then fetches the packets associated with the work unit from the one of caches 141 within the respective one of cores 140, and executes the invoked software function to process the packets. The one of cores 140 then outputs the corresponding results of processing the work unit back to WU queues 152. For example, upon processing the work unit, the one of cores 140 may generate a new work unit message by executing stored instructions to addresses mapped to a work unit transmit queue (e.g., another one of WU queues 152). The stored instructions write the contents of the message to the queue. The release of a work unit message from the one of cores 140 may be interlocked with (gated by) flushing of dirty data from the associated one of caches 141.
As one example use case, stream processing may be divided into work units executed at a number of intermediate processors between source and destination. Depending on the amount of work to be performed at each stage, the number and type of intermediate processors that are involved may vary. In processing a plurality of events related to each data packet, a first one of the plurality of cores 140, e.g., core 140A, may process a first event of the plurality of events. Moreover, first core 140A may provide to a second one of plurality of cores 140, e.g., core 140B, a first work unit of the one or more work units. Furthermore, second core 140B may process a second event of the plurality of events in response to receiving the first work unit from first core 140B.
As shown in
As shown in the example of
As described herein, each work unit within WU queues 340 is associated with one or more stream data units to be processed by the respective core. In one example, each work unit includes an association with (e.g., a pointer to) one or more data packets and may also include an association with (e.g., a pointer to) a work unit stack (“WU stack”) that carries program state, cached data and other information needed for program execution when processing the corresponding packets. As further described herein, in various examples, each work unit within WU queues 340 specifies (e.g., by an identifier or index) a software function F to be instantiated by dispatcher 330 for processing the work unit. In addition, each work unit includes an identifier for the core 350 or other hardware unit that sent the work unit and an identifier of the core 350 or other hardware unit to receive the work unit once processing is complete by the invoked software function F.
Upon instantiation by a dispatcher 330, the invoked software function F effectively provides seamless program execution to operate on the stream data units associated with the work unit using the program state, cached data and other information specified within the corresponding WU stack. During execution, the software function F may, for example, execute as a run-to-completion event handler for performing one or more particular operations on the stream data units. Moreover, continuity of program execution is maintained via the program state and cached data carried by the corresponding WU stack. While processing the work unit, the software function F may further manipulate the corresponding WU stack associated with the particular stream data units, e.g., data packets, by performing stack-like operations on the WU stack for the associated data packets and, optionally, directing the queue manager to create additional work units for further processing the associated data packets.
As further described herein, when processing a work unit, the corresponding instance of the software function F invoked by the dispatcher may perform stack-like operations on the WU stack flowing along with the data packets in the processing pipeline. In other words, the WU stack may be viewed as a set of work units that collectively implement an overall logical function, where the work units have not been yet been enqueued for processing. The work units are arranged in the WU stack in a stack format and may be manipulated (inserted, removed, etc.) by software functions F using stack operations to specify future work units for the overall logical function. The software function F may, for example, access a current frame within the WU stack for program state, cached data and any input or output variables for performing the corresponding function on the data packets. In addition, the software function may effectively ‘pop’ the current frame from the WU stack, push additional work unit frames on the WU stack, and/or cause additional work units to be created and enqueued within WU queues 340 for performing additional code portions (functions) on the work unit. In this way, the WU stack may be used to facilitate program execution and pipelining of an overall logical function using multiple software functions, where it is undesirable to execute all operations in a single run-to-completion event on a single core.
An application programming interface (API) may be utilized by software functions (F) for interacting with and manipulating the WU stacks associated with stream data units (e.g., data packets) being processed by the multiple processing cores. For example, a software function (F) can manipulate a WU stack by performing stack-like operations, such as allocating a WU stack, freeing a WU stack, pushing new frames onto an existing WU stack. In addition, the API may further allow a software function to send a continuation in association with a specific frame pushed on a WU stack, which in turn causes a work unit having a pointer to the frame to be enqueued in a WU queue for processing.
For processes, apparatuses, and other examples or illustrations described herein, including in any flowcharts or flow diagrams, certain operations, acts, steps, or events included in any of the techniques described herein can be performed in a different sequence, may be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the techniques). Moreover, in certain examples, operations, acts, steps, or events may be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors, rather than sequentially. Further certain operations, acts, steps, or events may be performed automatically even if not specifically identified as being performed automatically. Also, certain operations, acts, steps, or events described as being performed automatically may be alternatively not performed automatically, but rather, such operations, acts, steps, or events may be, in some examples, performed in response to input or another event.
The detailed description set forth above is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in the referenced figures in order to avoid obscuring such concepts.
In one or more examples, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored, as one or more instructions or code, on and/or transmitted over a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another (e.g., pursuant to a communication protocol). In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media, which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.
By way of example, and not limitation, such computer-readable storage media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.
Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the terms “processor” or “processing circuitry” as used herein may each refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described. In addition, in some examples, the functionality described may be provided within dedicated hardware and/or software modules. Also, the techniques could be fully implemented in one or more circuits or logic elements.
The techniques of this disclosure may be implemented in a wide variety of devices or apparatuses, including a wireless handset, a mobile or non-mobile computing device, a wearable or non-wearable computing device, an integrated circuit (IC) or a set of ICs (e.g., a chip set). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a hardware unit or provided by a collection of interoperating hardware units, including one or more processors as described above, in conjunction with suitable software and/or firmware.
Various examples have been described. These and other examples are within the scope of the following claims.
This application is a continuation application of U.S. application Ser. No. 16/031,945, filed on Jul. 10, 2018, which claims the benefit of U.S. Provisional Appl. No. 62/530,691, filed Jul. 10, 2017, U.S. Provisional Appl. No. 62/559,021, filed Sep. 15, 2017, and U.S. Provisional Appl. No. 62/589,427, filed Nov. 21, 2017, the entire content of each of which is incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4872157 | Hemmady et al. | Oct 1989 | A |
| 4872159 | Hemmady et al. | Oct 1989 | A |
| 5301324 | Dewey et al. | Apr 1994 | A |
| 5812549 | Sethu | Sep 1998 | A |
| 5828860 | Miyaoku et al. | Oct 1998 | A |
| 6021473 | Davis et al. | Feb 2000 | A |
| 6055579 | Goyal et al. | Apr 2000 | A |
| 6314491 | Freerksen et al. | Nov 2001 | B1 |
| 6647453 | Duncan et al. | Nov 2003 | B1 |
| 6842906 | Bowman-Amuah | Jan 2005 | B1 |
| 6901451 | Miyoshi et al. | May 2005 | B1 |
| 6901500 | Hussain et al. | May 2005 | B1 |
| 6993630 | Williams et al. | Jan 2006 | B1 |
| 7035914 | Payne et al. | Apr 2006 | B1 |
| 7082477 | Sadhasivam et al. | Jul 2006 | B1 |
| 7275103 | Thrasher et al. | Sep 2007 | B1 |
| 7289964 | Bowman-Amuah | Oct 2007 | B1 |
| 7342887 | Sindhu | Mar 2008 | B1 |
| 7480304 | Yeh et al. | Jan 2009 | B2 |
| 7486678 | Devanagondi et al. | Feb 2009 | B1 |
| 7664110 | Lovett et al. | Feb 2010 | B1 |
| 7733781 | Petersen | Jun 2010 | B2 |
| 7822731 | Yu et al. | Oct 2010 | B1 |
| 7843907 | Abou-Emara et al. | Nov 2010 | B1 |
| 7965624 | Ripa et al. | Jun 2011 | B2 |
| 7979588 | Tran et al. | Jul 2011 | B1 |
| 8386540 | McAlister et al. | Feb 2013 | B1 |
| 8560757 | Pangborn et al. | Oct 2013 | B2 |
| 8582440 | Ofelt et al. | Nov 2013 | B2 |
| 8599863 | Davis | Dec 2013 | B2 |
| 8625427 | Terry et al. | Jan 2014 | B1 |
| 8737410 | Davis et al. | May 2014 | B2 |
| 8798077 | Mehra et al. | Aug 2014 | B2 |
| 8848728 | Revah et al. | Sep 2014 | B1 |
| 8850101 | Pangborn et al. | Sep 2014 | B2 |
| 8850125 | Pangborn et al. | Sep 2014 | B2 |
| 8918631 | Kumar et al. | Dec 2014 | B1 |
| 8966152 | Bouchard et al. | Feb 2015 | B2 |
| 9065860 | Pangborn et al. | Jun 2015 | B2 |
| 9118984 | DeCusatis et al. | Aug 2015 | B2 |
| 9154376 | Aziz | Oct 2015 | B2 |
| 9225628 | Zahavi | Dec 2015 | B2 |
| 9244798 | Kuila et al. | Jan 2016 | B1 |
| 9262225 | Davis et al. | Feb 2016 | B2 |
| 9282384 | Graves | Mar 2016 | B1 |
| 9288101 | Dalal et al. | Mar 2016 | B1 |
| 9294304 | Sindhu | Mar 2016 | B2 |
| 9294398 | DeCusatis et al. | May 2016 | B2 |
| 9369408 | Raghavan et al. | Jun 2016 | B1 |
| 9405550 | Biran et al. | Aug 2016 | B2 |
| 9565114 | Kabbani et al. | Feb 2017 | B1 |
| 9569366 | Pangborn et al. | Feb 2017 | B2 |
| 9632936 | Zuckerman et al. | Apr 2017 | B1 |
| 9800495 | Lu | Oct 2017 | B2 |
| 9853901 | Kampmann et al. | Dec 2017 | B2 |
| 9866427 | Yadav et al. | Jan 2018 | B2 |
| 9876735 | Davis et al. | Jan 2018 | B2 |
| 9946671 | Tawri et al. | Apr 2018 | B1 |
| 10003552 | Kumar et al. | Jun 2018 | B2 |
| 10104171 | Savic et al. | Oct 2018 | B1 |
| 10135731 | Davis et al. | Nov 2018 | B2 |
| 10140245 | Davis et al. | Nov 2018 | B2 |
| 10304154 | Appu et al. | May 2019 | B2 |
| 10387179 | Hildebrant et al. | Aug 2019 | B1 |
| 10425707 | Sindhu et al. | Sep 2019 | B2 |
| 10540288 | Noureddine et al. | Jan 2020 | B2 |
| 10565112 | Noureddine et al. | Feb 2020 | B2 |
| 10637685 | Goel et al. | Apr 2020 | B2 |
| 10645187 | Goyal et al. | May 2020 | B2 |
| 10659254 | Sindhu et al. | May 2020 | B2 |
| 10686729 | Sindhu et al. | Jun 2020 | B2 |
| 10725825 | Sindhu et al. | Jul 2020 | B2 |
| 10761931 | Goyal et al. | Sep 2020 | B2 |
| 10827191 | Dikshit et al. | Nov 2020 | B2 |
| 10841245 | Gray et al. | Nov 2020 | B2 |
| 10929175 | Goyal et al. | Feb 2021 | B2 |
| 10951393 | Thomas et al. | Mar 2021 | B2 |
| 11048634 | Noureddine et al. | Jun 2021 | B2 |
| 20020015387 | Houh | Feb 2002 | A1 |
| 20020049859 | Bruckert et al. | Apr 2002 | A1 |
| 20020075862 | Mayes | Jun 2002 | A1 |
| 20020094151 | Li | Jul 2002 | A1 |
| 20020118415 | Dasylva et al. | Aug 2002 | A1 |
| 20020126634 | Mansharamani et al. | Sep 2002 | A1 |
| 20020126671 | Ellis et al. | Sep 2002 | A1 |
| 20030043798 | Pugel | Mar 2003 | A1 |
| 20030091271 | Dragone | May 2003 | A1 |
| 20030229839 | Wang et al. | Dec 2003 | A1 |
| 20040010612 | Pandya | Jan 2004 | A1 |
| 20040210320 | Pandya | Oct 2004 | A1 |
| 20040236912 | Glasco | Nov 2004 | A1 |
| 20050166086 | Watanabe | Jul 2005 | A1 |
| 20050259632 | Malpani et al. | Nov 2005 | A1 |
| 20060029323 | Nikonov et al. | Feb 2006 | A1 |
| 20060056406 | Bouchard | Mar 2006 | A1 |
| 20060059484 | Selvaggi et al. | Mar 2006 | A1 |
| 20060092976 | Lakshman et al. | May 2006 | A1 |
| 20060112226 | Hady et al. | May 2006 | A1 |
| 20060159103 | Jain et al. | Jul 2006 | A1 |
| 20060277421 | Balestriere | Dec 2006 | A1 |
| 20070073966 | Corbin | Mar 2007 | A1 |
| 20070172235 | Snider et al. | Jul 2007 | A1 |
| 20070192545 | Gara et al. | Aug 2007 | A1 |
| 20070198656 | Mazzaferri et al. | Aug 2007 | A1 |
| 20070255906 | Handgen et al. | Nov 2007 | A1 |
| 20080002702 | Bajic | Jan 2008 | A1 |
| 20080138067 | Beshai | Jun 2008 | A1 |
| 20080244231 | Kunze et al. | Oct 2008 | A1 |
| 20090024836 | Shen et al. | Jan 2009 | A1 |
| 20090083263 | Felch et al. | Mar 2009 | A1 |
| 20090135739 | Hoover et al. | May 2009 | A1 |
| 20090135832 | Fan et al. | May 2009 | A1 |
| 20090228890 | Vaitovirta et al. | Sep 2009 | A1 |
| 20090234987 | Lee et al. | Sep 2009 | A1 |
| 20090285228 | Bagepalli et al. | Nov 2009 | A1 |
| 20090303880 | Maltz et al. | Dec 2009 | A1 |
| 20100061391 | Sindhu et al. | Mar 2010 | A1 |
| 20100125903 | Devarajan et al. | May 2010 | A1 |
| 20100241831 | Mahadevan et al. | Sep 2010 | A1 |
| 20100293353 | Sonnier et al. | Nov 2010 | A1 |
| 20100318725 | Kwon | Dec 2010 | A1 |
| 20110289179 | Pekcan et al. | Jan 2011 | A1 |
| 20110055827 | Lin et al. | Mar 2011 | A1 |
| 20110113184 | Chu | May 2011 | A1 |
| 20110170553 | Beecroft et al. | Jul 2011 | A1 |
| 20110173392 | Gara et al. | Jul 2011 | A1 |
| 20110173514 | Pope | Jul 2011 | A1 |
| 20110202658 | Okuno et al. | Aug 2011 | A1 |
| 20110219145 | Pope | Sep 2011 | A1 |
| 20110222540 | Mital et al. | Sep 2011 | A1 |
| 20110225594 | Iyengar et al. | Sep 2011 | A1 |
| 20110228783 | Flynn et al. | Sep 2011 | A1 |
| 20110238923 | Hooker et al. | Sep 2011 | A1 |
| 20110289180 | Sonnier et al. | Nov 2011 | A1 |
| 20110289279 | Sonnier et al. | Nov 2011 | A1 |
| 20120030431 | Anderson et al. | Feb 2012 | A1 |
| 20120033680 | Gopinath | Feb 2012 | A1 |
| 20120036178 | Gavini et al. | Feb 2012 | A1 |
| 20120076153 | Manzella et al. | Mar 2012 | A1 |
| 20120096211 | Davis et al. | Apr 2012 | A1 |
| 20120176890 | Balus et al. | Jul 2012 | A1 |
| 20120177047 | Roitshtein | Jul 2012 | A1 |
| 20120207165 | Davis | Aug 2012 | A1 |
| 20120254587 | Biran et al. | Oct 2012 | A1 |
| 20120314710 | Shikano | Dec 2012 | A1 |
| 20130003725 | Hendel et al. | Jan 2013 | A1 |
| 20130024875 | Wang et al. | Jan 2013 | A1 |
| 20130028083 | Koshida et al. | Jan 2013 | A1 |
| 20130088971 | Anantharam et al. | Apr 2013 | A1 |
| 20130145375 | Kang | Jun 2013 | A1 |
| 20130191443 | Gan et al. | Jul 2013 | A1 |
| 20130258912 | Zimmerman et al. | Oct 2013 | A1 |
| 20130330076 | Liboiron-Ladouceur et al. | Dec 2013 | A1 |
| 20130346789 | Brunel et al. | Dec 2013 | A1 |
| 20140023080 | Zhang et al. | Jan 2014 | A1 |
| 20140040909 | Winser et al. | Feb 2014 | A1 |
| 20140044128 | Suresh et al. | Feb 2014 | A1 |
| 20140059537 | Kamble et al. | Feb 2014 | A1 |
| 20140075085 | Schroder et al. | Mar 2014 | A1 |
| 20140115122 | Yengalasetti | Apr 2014 | A1 |
| 20140161450 | Graves et al. | Jun 2014 | A1 |
| 20140181319 | Chen | Jun 2014 | A1 |
| 20140187317 | Kohler et al. | Jul 2014 | A1 |
| 20140258479 | Tenginakai et al. | Sep 2014 | A1 |
| 20140269351 | Graves et al. | Sep 2014 | A1 |
| 20140281243 | Shalf | Sep 2014 | A1 |
| 20140310467 | Shalf et al. | Oct 2014 | A1 |
| 20140359044 | Davis et al. | Dec 2014 | A1 |
| 20150019702 | Kancherla | Jan 2015 | A1 |
| 20150037032 | Xu et al. | Feb 2015 | A1 |
| 20150043330 | Hu et al. | Feb 2015 | A1 |
| 20150117860 | Braun | Apr 2015 | A1 |
| 20150143045 | Han et al. | May 2015 | A1 |
| 20150143073 | Winser et al. | May 2015 | A1 |
| 20150163171 | Sindhu et al. | Jun 2015 | A1 |
| 20150180603 | Darling et al. | Jun 2015 | A1 |
| 20150186313 | Sodhi et al. | Jul 2015 | A1 |
| 20150222533 | Birrittella et al. | Aug 2015 | A1 |
| 20150242324 | Novakovic et al. | Aug 2015 | A1 |
| 20150244617 | Nakil et al. | Aug 2015 | A1 |
| 20150254182 | Asher et al. | Sep 2015 | A1 |
| 20150256405 | Janardhanan et al. | Sep 2015 | A1 |
| 20150278148 | Sindhu | Oct 2015 | A1 |
| 20150278984 | Koker et al. | Oct 2015 | A1 |
| 20150279465 | Jokinen et al. | Oct 2015 | A1 |
| 20150280939 | Sindhu | Oct 2015 | A1 |
| 20150281128 | Sindhu | Oct 2015 | A1 |
| 20150324205 | Eisen et al. | Nov 2015 | A1 |
| 20150325272 | Murphy | Nov 2015 | A1 |
| 20150334034 | Smedley et al. | Nov 2015 | A1 |
| 20150334202 | Frydman et al. | Nov 2015 | A1 |
| 20150355946 | Kang | Dec 2015 | A1 |
| 20150378776 | Lippett | Dec 2015 | A1 |
| 20150381528 | Davis et al. | Dec 2015 | A9 |
| 20160056911 | Ye et al. | Feb 2016 | A1 |
| 20160062800 | Stanfill et al. | Mar 2016 | A1 |
| 20160085722 | Verplanken et al. | Mar 2016 | A1 |
| 20160092362 | Barron et al. | Mar 2016 | A1 |
| 20160164625 | Gronvall et al. | Jun 2016 | A1 |
| 20160188344 | Tamir et al. | Jun 2016 | A1 |
| 20160210159 | Wilson et al. | Jul 2016 | A1 |
| 20160239415 | Davis et al. | Aug 2016 | A1 |
| 20160241430 | Yadav et al. | Aug 2016 | A1 |
| 20160337723 | Graves | Nov 2016 | A1 |
| 20160364333 | Brown et al. | Dec 2016 | A1 |
| 20160364334 | Asaro et al. | Dec 2016 | A1 |
| 20160378538 | Kang | Dec 2016 | A1 |
| 20160380885 | Jani et al. | Dec 2016 | A1 |
| 20170005921 | Liu et al. | Jan 2017 | A1 |
| 20170031719 | Clark et al. | Feb 2017 | A1 |
| 20170032011 | Song et al. | Feb 2017 | A1 |
| 20170060615 | Thakkar et al. | Mar 2017 | A1 |
| 20170061566 | Min et al. | Mar 2017 | A1 |
| 20170068639 | Davis et al. | Mar 2017 | A1 |
| 20170083257 | Jain et al. | Mar 2017 | A1 |
| 20170214774 | Chen | Jul 2017 | A1 |
| 20170235581 | Nickoils et al. | Aug 2017 | A1 |
| 20170265220 | Andreoli-Fang et al. | Sep 2017 | A1 |
| 20170286143 | Wagner et al. | Oct 2017 | A1 |
| 20170286157 | Hasting et al. | Oct 2017 | A1 |
| 20170346766 | Dutta | Nov 2017 | A1 |
| 20180011739 | Pothula et al. | Jan 2018 | A1 |
| 20180024771 | Miller et al. | Jan 2018 | A1 |
| 20180026901 | Sugunadass | Jan 2018 | A1 |
| 20180054485 | Warfield | Feb 2018 | A1 |
| 20180095878 | Katayama | Apr 2018 | A1 |
| 20180115494 | Bhatia et al. | Apr 2018 | A1 |
| 20180145746 | Finkelstein | May 2018 | A1 |
| 20180152317 | Chang et al. | May 2018 | A1 |
| 20180234300 | Mayya et al. | Aug 2018 | A1 |
| 20180239702 | Farmahini Farahani et al. | Aug 2018 | A1 |
| 20180287818 | Goel et al. | Oct 2018 | A1 |
| 20180287965 | Sindhu et al. | Oct 2018 | A1 |
| 20180288505 | Sindhu et al. | Oct 2018 | A1 |
| 20180293168 | Noureddine et al. | Oct 2018 | A1 |
| 20180300928 | Koker et al. | Oct 2018 | A1 |
| 20180307494 | Ould-Ahmed-Vall et al. | Oct 2018 | A1 |
| 20180307535 | Suzuki et al. | Oct 2018 | A1 |
| 20180322386 | Sridharan et al. | Nov 2018 | A1 |
| 20180341494 | Sood | Nov 2018 | A1 |
| 20180357169 | Lai | Dec 2018 | A1 |
| 20180357172 | Lai | Dec 2018 | A1 |
| 20190005176 | Illikkal et al. | Jan 2019 | A1 |
| 20190012278 | Sindhu et al. | Jan 2019 | A1 |
| 20190012350 | Sindhu et al. | Jan 2019 | A1 |
| 20190013965 | Sindhu et al. | Jan 2019 | A1 |
| 20190018806 | Koufaty et al. | Jan 2019 | A1 |
| 20190042292 | Palermo et al. | Feb 2019 | A1 |
| 20190042518 | Marolia et al. | Feb 2019 | A1 |
| 20190095333 | Heirman et al. | Mar 2019 | A1 |
| 20190102311 | Gupta et al. | Apr 2019 | A1 |
| 20190104057 | Goel et al. | Apr 2019 | A1 |
| 20190104206 | Goel et al. | Apr 2019 | A1 |
| 20190104207 | Goel et al. | Apr 2019 | A1 |
| 20190158428 | Gray et al. | May 2019 | A1 |
| 20190188079 | Kohli | Jun 2019 | A1 |
| 20190243765 | Noureddine et al. | Aug 2019 | A1 |
| 20190363989 | Shalev et al. | Nov 2019 | A1 |
| 20200007405 | Chitalia | Jan 2020 | A1 |
| 20200021664 | Goyal et al. | Jan 2020 | A1 |
| 20200021898 | Sindhu et al. | Jan 2020 | A1 |
| 20200028776 | Atli | Jan 2020 | A1 |
| 20200042479 | Wang | Feb 2020 | A1 |
| 20200067839 | Iny et al. | Feb 2020 | A1 |
| 20200119903 | Thomas et al. | Apr 2020 | A1 |
| 20200133771 | Goyal et al. | Apr 2020 | A1 |
| 20200145680 | Dikshit et al. | May 2020 | A1 |
| 20200151101 | Noureddine et al. | May 2020 | A1 |
| 20200159568 | Goyal et al. | May 2020 | A1 |
| 20200159859 | Beckman et al. | May 2020 | A1 |
| 20200169513 | Goel et al. | May 2020 | A1 |
| 20200183841 | Noureddine et al. | Jun 2020 | A1 |
| 20200259682 | Goel et al. | Aug 2020 | A1 |
| 20200264914 | Dasgupta | Aug 2020 | A1 |
| 20200280462 | Sindhu et al. | Sep 2020 | A1 |
| 20200314026 | Sindhu et al. | Oct 2020 | A1 |
| 20200356414 | Sindhu | Nov 2020 | A1 |
| 20210117242 | Van De Groenendaal | Apr 2021 | A1 |
| 20220116487 | Sundar | Apr 2022 | A1 |
| 20220279421 | Sivakumar | Sep 2022 | A1 |
| 20220286399 | McDonnell | Sep 2022 | A1 |
| Number | Date | Country |
|---|---|---|
| 101447986 | Jun 2009 | CN |
| 103004158 | Mar 2013 | CN |
| 104052618 | Sep 2014 | CN |
| 104521196 | Apr 2015 | CN |
| 104954247 | Sep 2015 | CN |
| 104954251 | Sep 2015 | CN |
| 105024844 | Nov 2015 | CN |
| 1079571 | Feb 2001 | EP |
| 1489796 | Dec 2004 | EP |
| 1501246 | Jan 2005 | EP |
| 2289206 | Mar 2011 | EP |
| 2928134 | Jul 2015 | EP |
| 2009114554 | Sep 2009 | WO |
| 2013184846 | Dec 2013 | WO |
| 2014178854 | Nov 2014 | WO |
| 2016037262 | Mar 2016 | WO |
| 2019014268 | Jan 2019 | WO |
| Entry |
|---|
| U.S. Appl. No. 17/360,619, filed Jun. 28, 2021, naming inventors Noureddine et al. |
| Notice of Allowance from U.S. Appl. No. 16/877,050 dated Sep. 6, 2022, 10 pp. |
| Response to Office Action dated Apr. 14, 2022 from U.S. Appl. No. 16/877,050, filed Jul. 14, 2022, 11 pp. |
| “QFX10000 Switches System Architecture,” White Paper, Juniper Networks, Apr. 2015, 15 pp. |
| Advisory Action from U.S. Appl. No. 16/031,921, dated Jun. 12, 2020, 8 pp. |
| Adya et al., “Cooperative Task Management without Manual Stack Management,” Proceedings of the 2002 Usenix Annual Technical Conference, Jun. 2002, 14 pp. |
| Al-Fares et al., “Hedera: Dynamic Flow Scheduling for Data Center Networks,” NSDI'10 Proceedings of the 7th USENIX Conference on Networked Systems Design and Implementation, Apr. 28-30, 2010, 15 pp. |
| Alizadeh et al., “CONGA: Distributed Congestion-Aware Load Balancing for Datacenters,” SIGCOMM '14 Proceedings of the 2014 ACM Conference on SIGCOMM, Aug. 17-22, 2014, pp. 503-514. |
| Amendment in Response to Final Office Action dated Mar. 27, 2020 from U.S. Appl. No. 16/031,921, filed May 27, 2020, 17 pp. |
| Amendment in Response to Office Action dated Nov. 18, 2019, from U.S. Appl. No. 16/031,921, filed Mar. 18, 2020,16 pp. |
| Bakkum et al., “Accelerating SQL Database Operations on a GPU with CUDA,” Proceedings of the 3rd Workshop on Genral-Purpose Computation on Graphics Processing Units, Mar. 14, 2010, 10 pp. |
| Banga et al., “Better operating system features for faster network servers,” ACM Sigmetrics Performance Evaluation Review, vol. 26, Issue 3, Dec. 1998, 11 pp. |
| Barroso et al., “Attack of the killer Microseconds,” Communications of the ACM, vol. 60, No. 4, Apr. 2017, 7 pp. |
| Benson et al., “MicroTE: Fine Grained Traffic Engineering for Data Centers,” CoNEXT '11 Proceedings of the Seventh Conference on emerging Networking Experiments and Technologies Article No. 8, Dec. 6-9, 2011, 12 pp. |
| Benson et al., “Network Traffic Characteristics of Data Centers in the Wild,” IMC '10 Proceedings of the 10th ACM SIGCOMM Conference on Internet Measurement, Nov. 1-30, 2010, pp. 267-280. |
| Deutsch, “DEFLATE Compressed Data Format Specification version 1.3,” IETF Network Working Group, RFC 1951, May 1996, 15 pp. |
| Final Office Action from U.S. Appl. No. 16/031,921, dated Mar. 27, 2020, 48 pp. |
| Ford et al., “TCP Extensions for Multipath Operation with Multiple Addresses,” Internet Engineering Task Force (IETF), RFC 6824, Jan. 2013, 64 pp. |
| Friedman et al., “Programming with Continuations,” Technical Report 151, Nov. 1983, 14 pp. |
| Gay et al., “The nesC Language: A Holistic Approach to Networked Embedded Systems,” accessed from http://nescc.sourceforge.net, last updated Dec. 14, 2004, 11 pp. |
| Halbwachs et al., “The Synchronous Data Flow Programming Language LUSTRE,” Proceedings of the IEEE, vol. 79, No. 9, Sep. 1991, 16 pp. |
| Haynes et al., “Continuations and Coroutines,” Technical Report No. 158, Jun. 1984, 19 pp. |
| Hewitt, “Viewing Control Structures as Patterns of Passing Messages,” Massachusetts Institute of Technology, Artificial Intelligence Laboratory, Dec. 1976, 61 pp. |
| Hseush et al., Data Path Debugging: Data-Oriented Debugging for a Concurrent Programming Language, PADD 88 Proceedings of the 1988 ACM SIGPLAN and SIGOPS workshop on Parallel and distributed debugging, May 5-6, 1988, 12 pp. |
| Huang et al., “Erasure Coding in Windows Azure Storage,” 2012 USENIX Annual Technical Conference, Jun. 13-15, 2012, 12 pp. |
| Hurson, “Advances in Computers, vol. 92,” Jan. 13, 2014, Academic Press, XP055510879, 94-95 pp. |
| International Preliminary Report on Patentability from International Application No. PCT/US2018/041510, dated Jul. 10, 2019, 6 pp. |
| Isen et al., “ESKIMO—Energy Savings using Semantic Knowledge of Inconsequential Memory Occupancy for DRAM subsystem,” 42nd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), Dec. 12-16, 2009, 10 pp. |
| Kahn et al., “Actors as a Special Case of Concurrent Constraint Programming,” ECOOP/OOPSLA '90 Proceedings, Oct. 21-25, 1990, 10 pp. |
| Kaminow, “Optical Integrated Circuits: A Personal Perspective,” Journal of Lightwave Technology, vol. 26, No. 9, May 1, 2008, pp. 994-1004. |
| Kandula et al., “Dynamic Load Balancing Without Packet Reordering,” SIGCOMM Computer Communication Review, vol. 37, No. 2, Apr. 2007, pp. 53-62. |
| Kandula et al.,“ The Nature of Datacenter Traffic: Measurements & Analysis,” IMC '09 Proceedings of the 9th ACM SIGCOMM conference on Internet measurement, Nov. 4-6, 2009, pp. 202-208. |
| Kelly et al., A Block Diagram Compiler, The Bell System Technical Journal, Dec. 7, 1960, 10 pp. |
| Kounavis et al., “Programming the data path in network processor-based routers,” Software-Practice and Experience, Oct. 21, 2003, 38 pp. |
| Larus et al., “Using Cohort Scheduling to Enhance Server Performance,” Usenix Annual Technical Conference, Jun. 2002, 12 pp. |
| Levis et al., “Tiny OS: An Operating System for Sensor Networks,” Ambient Intelligence, Jan. 2005, 34 pp. |
| Lin et al., A Parameterized Dataflow Language Extension for Embedded Streaming Systems, 2008 International Conference on Embedded Computer Systems: Architectures, Modeling, and Simulation, Jul. 21-24, 2008, 8 pp. |
| Mishra et al., “Thread-based vs Event-based Implementation of a Group Communication Service,” Proceedings of the First Merged International Parallel Processing Symposium and Symposium on Parallel and Distributed Processing, Mar. 30-Apr. 3, 1998, 5 pp. |
| Notice of Allowance from U.S. Appl. No. 16/031,676, dated Jan. 13, 2020, 16 pp. |
| Office Action from U.S. Appl. No. 16/031,921, dated Nov. 18, 2019, 39 pp. |
| Prosecution History from U.S. Appl. No. 16/031,945, dated Jan. 24, 2020 through Jun. 30, 2020, 40 pp. |
| Raiciu et al., “Improving Datacenter Performance and Robustness with Multipath TCP,” ACM SIGCOMM Computer Communication Review—SIGCOMM '11, vol. 41, No. 4, Aug. 2011, pp. 266-277. |
| Response to Written Opinion from International Application No. PCT/US2018/041510, filed May 10, 2019, 8 pp. |
| Schroeder et al., “Flash Reliability in Production: The Expected and the Unexpected,” 14th USENIX Conference on File and Storage Technologies (FAST '16), Feb. 22-25, 2016, 15 pp. |
| Varela et al., “The Salsa Programming Language 2.0.0alpha Release Tutorial,” Tensselaer Polytechnic Institute, Nov. 2009, 52 pp. |
| Von Behren et al., “Why Events are a Bad Idea (for high-concurrency servers),” Proceedings of HotOS IX, May 2003, 6 pp. |
| Wang et al., “A Spatial and Temporal Locality-Aware Adaptive Cache Design with Network Optimization for Tiled Many-Core Architectures,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 25. No. 9, Sep. 2017, pp. 2419-2433. |
| Welsh et al., “SEDA: An Architecture for Well-Conditioned, Scalable Internet Services,” Eighteenth Symposium on Operating Systems Principles, Oct. 21-24, 2001, 14 pp. |
| Zhu et al., “Congestion Control for Large-Scale RDMA Deployments,” SIGCOMM '15 Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication, Aug. 17-21, 2015, pp. 523-536. |
| Prosecution History from U.S. Appl. No. 16/197,179, dated Mar. 10, 2020 through Oct. 19, 2020, 51 pp. |
| Prosecution History from U.S. Appl. No. 16/198,607, dated May 1, 2020 through Oct. 23, 2020, 30 pp. |
| Notice of Allowance from U.S. Appl. No. 16/031,921, dated Dec. 14, 2021, 8 pp. |
| U.S. Appl. No. 17/657,081, filed Mar. 29, 2022, naming inventors Sindu et al. |
| Office Action from U.S Appl. No. 16/877,050, dated Apr. 14, 2022,13 pp. |
| Office Action from U.S. Appl. No. 17/657,081, dated Mar. 2, 2023,13 pp. |
| Patterson et al., “Chapter 16: Informed Prefetching and Caching,” Proceedings of the 5th International Symposium on High Performance Computer Architecture, Jan. 1999, pp. 224-244. |
| “First Office Action Issued in Chinese Patent Application No. 201880046042.5”, dated Dec. 26, 2022, 27 Pages. |
| “Notice of Allowance Issued in U.S. Appl. No. 17/657,081”, dated Jul. 12, 2023, 8 Pages. |
| US-2022-0224564-A1, Sindhu et al., filed Jul. 14, 2022. |
| U.S. Pat. No. 11,303,472, Sindhu et al., filed Apr. 12, 2022. |
| U.S. Pat. No. 10,725,825, Sindhu et al., filed Jul. 28, 2020. |
| U.S. Pat. No. 11,546,189, Sindhu et al., filed Jan. 3, 2023. |
| U.S. Pat. No. 10,659,254, Gray et al., filed May 19, 2020. |
| U.S. Pat. No. 10,841,245, Gray et al., filed Nov. 17, 2020. |
| “Notice of Allowance Issued in Chinese Patent Application No. 201880046042.5”, dated May 29, 2023, 4 Pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20200356414 A1 | Nov 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62589427 | Nov 2017 | US | |
| 62559021 | Sep 2017 | US | |
| 62530691 | Jul 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16031945 | Jul 2018 | US |
| Child | 16939617 | US |
