Patent Application
20130318280
The present disclosure relates generally to servers, and more particularly to offload or auxiliary processing modules that can be physically connected to a system memory bus to process data independent of a host processor of the server.
Networked applications often run on dedicated servers that support an associated “state” for context or session-defined application. Servers can run multiple applications, each associated with a specific state running on the server. Common server applications include an Apache web server, a MySQL database application, PHP hypertext preprocessing, video or audio processing with Kaltura supported software, packet filters, application cache, management and application switches, accounting, analytics, and logging.
Unfortunately, servers can be limited by computational and memory storage costs associated with switching between applications. When multiple applications are constantly required to be available, the overhead associated with storing the session state of each application can result in poor performance due to constant switching between applications. Dividing applications between multiple processor cores can help alleviate the application switching problem, but does not eliminate it, since even advanced processors often only have eight to sixteen cores, while hundreds of application or session states may be required.
A methods for handling multiple networked applications using a distributed server system can include providing at least one main processor and a plurality of offload processors connected to a memory bus; providing an arbiter connected to each of the plurality of offload processors, the arbiter capable of scheduling resource priority for instructions or data received from the memory bus; and operating a virtual switch respectively connected to the main processor and the plurality of offload processors using the memory bus, with the virtual switch capable of receiving memory read/write data over the memory bus; and directing at least some memory read/write data to the arbiter from the virtual switch.
Networked applications are available that run on servers and have associated with them a state (session-defined applications). The session nature of such applications allows them to have an associated state and a context when the session is running on the server. Further, if such session-limited applications are computationally lightweight, they can be run in part or fully on the auxiliary or additional processor cores (such as those based on the ARM architecture, as but one particular example) which are mounted on modules connected to a memory bus, for example, by insertion into a socket for a Dual In-line Memory Module (DIMM). Such modules can be referred to as a Xocket™ In-line Memory Module (XIMM), and have multiple cores (e.g., ARM cores) associated with a memory channel. A XIMM can access the network data through an intermediary virtual switch (such as OpenFlow or similar) that can identify sessions and direct the network data to the corresponding module (XIMM) mounted cores, where the session flow for the incoming network data can be handled.
As will be appreciated, through usage of a large prefetch buffer or low latency memory, the session context of each of the sessions that are run on the processor cores of a XIMM can be stored external to the cache of such processor cores. By systematically engineering the transfer of cache context to a memory external to the module processors (e.g., RAMs) and engineering low latency context switch, it is possible to execute several high-bandwidth server applications on a XIMM provided the applications are not computationally intensive. The “wimpy” processor cores of a XIMM can be favorably disposed to handle high network bandwidth traffic at a lower latency and at a very low power when compared to traditional high power ‘brawny’ cores.
In effect, one can reduce problems associated with session limited servers by using the module processor (e.g., an ARM architecture processor) of a XIMM to offload part of the functionality of traditional servers. Module processor cores may be suited to carry computationally simple or lightweight applications such as packet filtering or packet logging functions. They may also be suited for providing the function of an application cache for handling hot-code that is to be serviced very frequently to incoming streams. Module processor cores can also be suited for functions such as video streaming/real time streaming, that often only require light-weight processing.
As an example of partitioning applications between a XIMM with “wimpy” ARM cores and a conventional “brawny” core (e.g., x86 or Itanium server processor with Intel multicore processor), a computationally lightweight Apache web server can be hosted on one or more XIMMs with ARM cores, while computationally heavy MySQL and PHP are hosted on x86 brawny cores. Similarly, lightweight applications such as a packet filter, application cache, management and application switch are hosted on XIMM(s), while x86 cores host control, accounting, analytics and logging.
According to some embodiments, a web server running Apache-MySQL-PHP (AMP) can be used to service clients that send requests to the server module 140 from network 120. The embodiment of
The computation and dynamic behavior associated with the web pages can be rendered by PHP or such other server side scripts running on the brawny cores 108. The brawny cores might also have code/scripting libraries for interacting with MySQL databases stored in hard disks present in said server module 140. The wimpy cores (112a to 112c), on receiving queries or user requests from clients, transfer embedded PHP/MySQL queries to said brawny cores over a connection (e.g., an Ethernet-type connection) that is tunneled on a memory bus such as a DDR bus. The PHP interpreter on brawny cores 108 interfaces and queries a MySQL database and processes the queries before transferring the results to the wimpy cores (112a to 112c) over said connection. The wimpy cores (112a to 112c) can then service the results obtained to the end user or client.
Given that the server code lacking server side script is computationally light weight, and many Web API types are Representational State Transfer (REST) based and require only HTML processing, and on most occasions require no persistent state, wimpy cores (112a to 112c) can be highly suited to execute such light weight functions. When scripts and computation is required, the computation is handled favorably by brawny cores 108 before the results are serviced to end users. The ability to service low computation user queries with a low latency, and the ability to introduce dynamicity into the web page by supporting server-side scripting make the combination of wimpy and brawny cores an ideal fit for traditional web server functions. In the enterprise and private datacenter, simple object access protocol (SOAP) is often used, making the ability to context switch with sessions performance critical, and the ability of wimpy cores to save the context in an extended cache can enhance performance significantly.
Each of the wimpy processor cores (e.g., ARM cores) (212a to 212c) can be mounted on an in-memory module (not shown) and each of them can be allocated a memory channel (210a to 210c). At least one of the wimpy processor cores (212a to 212c) can be capable of running a tight, computationally light weight web server code for servicing applications that need to be transmitted with a very low latency/jitter. Example applications such as video, audio, or voice over IP (VoIP) streaming involve client requests that need to be handled with as little latency as possible. One particular protocol suitable for the disclosed embodiment is Real-Time Transport Protocol (RTP), an Internet protocol for transmitting real-time data such as audio and video. RTP itself does not guarantee real-time delivery of data, but it does provide mechanisms for the sending and receiving applications to support streaming data.
Brawny processor core(s) 208 can be connected by bus 206 to switch 204 (which may be an OpenFlow or other virtual switch). In one embodiment, such a bus 206 can be a front side bus.
In operation, server module 240 can handle several client requests and services information in real time. The stateful nature of applications such as RTP/video streaming makes the embodiment amenable to handle several queries at a very high throughput. The embodiment can have an engineered low latency context overhead system that enables wimpy cores (212a to 212c) to shift from servicing one session to another session in real time. Such a context switch system can enable it to meet the quality of service (QoS) and jitter requirements of RTP and video traffic. This can provide substantial performance improvement if the overlay control plane and data plane (for handling real time applications related traffic) is split across a brawny processor 208 and a number of wimpy cores (212a to 212c). The wimpy cores (212a to 212c) can be favorably suited to handling the data plane and servicing the actual streaming of data in video/audio streaming or RTP applications. The ability of wimpy cores (212a to 212c) to switch between multiple sessions with low latency makes them suitable for handling of the data plane.
For example, wimpy cores (212a to 212c) can run code that quickly constructs data that is in an RTP format by concatenating data (that is available locally or through direct memory access (DMA) from main memory or a hard disk) with sequence number, synchronization data, timestamp etc., and sends it over to clients according to a predetermined protocol. The wimpy cores (212a to 212c) can be capable of switching to a new session/new client with a very low latency and performing a RTP data transport for the new session. The brawny cores 208 can be favorably suited for overlay control plane functionality.
The overlay control plane can often involve computationally expensive actions such as setting up a session, monitoring session statistics, and providing information on QoS and feedback to session participants. The overlay control plane and the data plane can communicate over a connection (e.g., an Ethernet-type connection) that is tunneled on a memory bus such as a DDR bus. Typically, overlay control can establish sessions for features such as audio/videoconferencing, interactive gaming, and call forwarding to be deployed over IP networks, including traditional telephony features such as personal mobility, time-of-day routing and call forwarding based on the geographical location of the person being called. For example, the overlay control plane can be responsible for executing RTP control protocol (RTCP, which forms part of the RTP protocol used to carry VoIP communications and monitors QoS); Session Initiation Protocol (SIP, which is an application-layer control signaling protocol for Internet Telephony); Session Description Protocol (SDP, which is a protocol that defines a text-based format for describing streaming media sessions and multicast transmissions); or other low latency data streaming protocols.
In particular embodiments, in some embodiments, a rack server module 240 further includes a switch (100), which can provide input-out memory management unit (IOMMU) functions 302 and a switch 304 (which may be an OpenFlow or other virtual switch). Brawny processor core(s) 308 can be connected to switch 304 by bus 306, which can be a front side bus. A traditional server module 360 can also include a switch 324 can provide IOMMU functions 326.
The following example(s) provide illustration and discussion of exemplary hardware and data processing systems suitable for implementation and operation of the foregoing discussed systems and methods. In particular hardware and operation of wimpy cores or computational elements connected to a memory bus and mounted in DIMM or other conventional memory socket is discussed.
The computation elements or offload processors can be accessible through memory bus 405. In this embodiment, the module can be inserted into a Dual Inline Memory Module (DIMM) slot on a commodity computer or server using a DIMM connector (407), providing a significant increase in effective computing power to system 400. The module (e.g., XIMM) may communicate with other components in the commodity computer or server via one of a variety of busses including but not limited to any version of existing double data rate standards (e.g., DDR, DDR2, DDR3, etc.)
This illustrated embodiment of the module 402 contains five offload processors (400a, 400b, 400c, 400d, 400e) however other embodiments containing greater or fewer numbers of processors are contemplated. The offload processors (400a to 400e) can be custom manufactured or one of a variety of commodity processors including but not limited to field-programmable grid arrays (FPGA), microprocessors, reduced instruction set computers (RISC), microcontrollers or ARM processors. The computation elements or offload processors can include combinations of computational FPGAs such as those based on Altera, Xilinx (e.g., Artix™ class or Zynq® architecture, e.g., Zynq® 7020), and/or conventional processors such as those based on Intel Atom or ARM architecture (e.g., ARM A9). For many applications, ARM processors having advanced memory handling features such as a snoop control unit (SCU) are preferred, since this can allow coherent read and write of memory. Other preferred advanced memory features can include processors that support an accelerator coherency port (ACP) that can allow for coherent supplementation of the cache through an FPGA fabric or computational element.
Each offload processor (400a to 400e) on the module 402 may run one of a variety of operating systems including but not limited to Apache or Linux. In addition, the offload processors (400a to 400e) may have access to a plurality of dedicated or shared storage methods. In this embodiment, each offload processor can connect to one or more storage units (in this embodiments, pairs of storage units 404a, 404b, 404c and 404d). Storage units (404a to 404d) can be of a variety of storage types, including but not limited to random access memory (RAM), dynamic random access memory (DRAM), sequential access memory (SAM), static random access memory (SRAM), synchronous dynamic random access memory (SDRAM), reduced latency dynamic random access memory (RLDRAM), flash memory, or other emerging memory standards such as those based on DDR4 or hybrid memory cubes (HMC).
In this embodiment, one of the Zynq® computational FPGAs (416a to 416e) can act as arbiter providing a memory cache, giving an ability to have peer to peer sharing of data (via memcached or OMQ memory formalisms) between the other Zynq® computational FPGAs (416a to 416e). Traffic departing for the computational FPGAs can be controlled through memory mapped I/O. The arbiter queues session data for use, and when a computational FPGA asks for address outside of the provided session, the arbiter can be the first level of retrieval, external processing determination, and predictors set.
Operation of one embodiment of a module 430 (e.g., XIMM) using an ARM A9 architecture is illustrated with respect to
The following table (Table 1) illustrates potential states that can exist in the scheduling of queues/threads to XIMM processors and memory such as illustrated in
These states can help coordinate the complex synchronization between processes, network traffic, and memory-mapped hardware. When a queue is selected by a traffic manager a pipeline coordinates swapping in the desired L2 cache (440), transferring the reassembled IO data into the memory space of the executing process. In certain cases, no packets are pending in the queue, but computation is still pending to service previous packets. Once this process makes a memory reference outside of the data swapped, a scheduler can require queued data from a network interface card (NIC) to continue scheduling the thread. To provide fair queuing to a process not having data, the maximum context size is assumed as data processed. In this way, a queue must be provisioned as the greater of computational resource and network bandwidth resource, for example, each as a ratio of an 800 MHz A9 and 3 Gbps of bandwidth. Given the lopsidedness of this ratio, the ARM core is generally indicated to be worthwhile for computation having many parallel sessions (such that the hardware's prefetching of session-specific data and TCP/reassembly offloads a large portion of the CPU load) and those requiring minimal general purpose processing of data.
Essentially zero-overhead context switching is also possible using modules as disclosed in
In operation, metadata transport code can relieve a main or host processor from tasks including fragmentation and reassembly, and checksum and other metadata services (e.g., accounting, IPSec, SSL, Overlay, etc.). As 10 data streams in and out, L1 cache 437 can be filled during packet processing. During a context switch, the lock-down portion of a translation lookaside buffer (TLB) of an L1 cache can be rewritten with the addresses corresponding to the new context. In one very particular implementation, the following four commands can be executed for the current memory space.
MRC p15,0,r0,c10,c0,0; read the lockdown register
BIC r0,r0,#1; clear preserve bit
MCR p15,0,r0,c10,c0,0; write to the lockdown register;
write to the old value to the memory mapped Block RAM
This is a small 32 cycle overhead to bear. Other TLB entries can be used by the XIMM stochastically.
Bandwidths and capacities of the memories can be precisely allocated to support context switching as well as applications such as Openflow processing, billing, accounting, and header filtering programs.
For additional performance improvements, the ACP 434 can be used not just for cache supplementation, but hardware functionality supplementation, in part by exploitation of the memory space allocation. An operand can be written to memory and the new function called, through customizing specific Open Source libraries, so putting the thread to sleep and a hardware scheduler can validate it for scheduling again once the results are ready. For example, OpenVPN uses the OpenSSL library, where the encrypt/decrypt functions 439 can be memory mapped. Large blocks are then available to be exported without delay, or consuming the L2 cache 440, using the ACP 434. Hence, a minimum number of calls are needed within the processing window of a context switch, improving overall performance.
A memory interface 504 can detect data transfers on a system memory bus, and in appropriate cases, enable write data to be stored in the processing module 500 and/or read data to be read out from the processing module 500. In some embodiments, a memory interface 504 can be a slave interface, thus data transfers are controlled by a master device separate from the processing module. In very particular embodiments, a memory interface 504 can be a direct memory access (DMA) slave, to accommodate DMA transfers over a system memory initiated by a DMA master. Such a DMA master can be a device different from a host processor. In such configurations, processing module 500 can receive data for processing (e.g., DMA write), and transfer processed data out (e.g., DMA read) without consuming host processor resources.
Arbiter logic 506 can arbitrate between conflicting data accesses within processing module 500. In some embodiments, arbiter logic 506 can arbitrate between accesses by offload processor 508 and accesses external to the processor module 500. It is understood that a processing module 500 can include multiple locations that are operated on at the same time. It is also understood that accesses that are arbitrated by arbiter logic 506 can include accesses to physical system memory space occupied by the processor module 500, as well as accesses to resources (e.g., processor resources). Accordingly, arbitration rules for arbiter logic 506 can vary according to application. In some embodiments, such arbitration rules are fixed for a given processor module 500. In such cases, different applications can be accommodated by switching out different processing modules. However, in alternate embodiments, such arbitration rules can be configurable while the module is connected to a data bus.
Offload processor(s) 508 can include one or more processors that can operate on data transferred over the system memory bus. In some embodiments, offload processors can run a general operating system, enabling processor contexts to be saved and retrieved. Computing tasks executed by offload processor 508 can be controlled by control logic 512. Offload processor(s) 508 can operate on data buffered in the processing module 500. In addition or alternatively, offload processor(s) 508 can access data stored elsewhere in a system memory space. In some embodiment, offload processor(s) 508 can include a cache memory configured to store context information. An offload processor(s) 508 can include multiple cores or one core.
A processing module 500 can be included in a system having a host processor (not shown). In some embodiments, offload processors 508 can be a different type of processor as compared to the host processor. In particular embodiments, offload processors 508 can consume less power and/or have less computing power than a host processor. In very particular embodiments, offload processors 508 can be “wimpy” core processors, while a host processor can be a “brawny” core processor. In alternate embodiments, offload processors 508 can have equivalent or greater computing power than any host processor.
Local memory 510 can be connected to offload processor(s) 508 to enable the storing of context information. Accordingly, offload processor(s) 508 can store current context information, and then switch to a new computing task, then subsequently retrieve the context information to resume the prior task. In very particular embodiments, local memory 510 can be a low latency memory with respect to other memories in a system. In some embodiments, storing of context information can include copying a cache of an offload processor 508 to the local memory 510.
In some embodiments, a same space within local memory 510 is accessible by multiple offload processors 508 of the same type. In this way, a context stored by one offload processor can be resumed by a different offload processor.
Control logic 512 can control processing tasks executed by offload processor(s) 508. In some embodiments, control logic 512 can be considered a hardware scheduler that can be conceptualized as including a data evaluator 514, scheduler 516 and a switch controller 518. A data evaluator 514 can extract “metadata” from write data transferred over a system memory bus. “Metadata”, as used herein, can be any information embedded at one or more predetermined locations of a block of write data that indicates processing to be performed on all or a portion of the block of write data. In some embodiments, metadata can be data that indicates a higher level organization for the block of write data. As but one very particular embodiment, metadata can be header information of network packet (which may or may not be encapsulated within a higher layer packet structure).
A scheduler 516 can order computing tasks for offload processor(s) 508. In some embodiments, scheduler 516 can generate a schedule that is continually updated as write data for processing is received. In very particular embodiments, a scheduler 516 can generate such a schedule based on the ability to switch contexts of offload processor(s) 508. In this way, module computing priorities can be adjusted on the fly. In very particular embodiments, a scheduler 516 can assign a portion of physical address space to an offload processor 508, according to computing tasks. The offload processor 508 can then switch between such different spaces, saving context information prior to each switch, and subsequently restoring context information when returning to the memory space.
Switch controller 518 can control computing operations of offload processor(s) 508. In particular embodiments, according to scheduler 516, switch controller 518 can order offload processor(s) 510 to switch contexts. It is understood that a context switch operation can be an “atomic” operation, executed in response to a single command from switch controller 518. In addition or alternatively, a switch controller 518 can issue an instruction set that stores current context information, recalls context information, etc.
In some embodiments, processing module 500 can include a buffer memory (not shown). A buffer memory can store received write data on-board the processor module 500. A buffer memory can be implemented on an entirely different set of memory devices, or can be a memory embedded with logic and/or the offload processor. In the latter case, arbiter logic 506 can arbitrate access to the buffer memory. In some embodiments, a buffer memory can correspond to a portion of a system physical memory space. The remaining portion of the system memory space can correspond to other like processor modules and/or memory modules connected to the same system memory bus. In some embodiments buffer memory can be different than local memory 510. For example, buffer memory can have a slower access time than a local memory 510. However, in other embodiments, buffer memory and local memory can be implemented with like memory devices.
In very particular embodiments, write data for processing can have an expected maximum flow rate. A processor module 500 can be configured to operate on such data at, or faster than, such a flow rate. In this way, a master device (not shown) can write data to a processor module without danger of overwriting data “in process”.
The various computing elements of a processor module 500 can be implemented as one or more integrated circuit devices (ICs). It is understood that the various components shown in
It is understood that
In some embodiments, a processor module 500 can occupy one slot. However, in other embodiments, a processor module can occupy multiple slots (i.e., include more than one connection). In some embodiments, a system memory bus 528 can be further interfaced with one or more host processors and/or input/output devices (not shown).
Having described processor modules according to various embodiments, operations of a processor module according to particular embodiments will now be described.
Referring to
Control logic 512 can access metadata (MD) of the write data 534-0 to determine a type of processing to be performed (circle “2”). In some embodiments, such an action can include a direct read from a physical address (i.e., MD location is at a predetermined location). In addition or alternatively, such an action can be an indirect read (i.e., MD is accessed via pointer, or the like). The action shown by circle “2” can be performed by any of: a read by control logic 512 or read by an offload processor 508. From extracted metadata, scheduler 516 can create a processing schedule, or modify an existing schedule to accommodate the new computing task (circle “3”).
Referring to
Referring to
Referring to
Referring to
Referring to
A method 540 can determine if current offload processing is sufficient for a new session or change of session 544. Such an action take into account a processing time required for any current sessions.
If current processing resources can accommodate new session requirements (Y from 544), a hardware schedule (schedule for controlling offload processor(s)) can be revised and the new session can be assigned to an offload processor. If current processing resources cannot accommodate new session requirements (N from 544), one or more offload processors can be selected for re-tasking (e.g., a context switch) 550 and the hardware schedule can be modified accordingly 552. The selected offload processors can save their current context data 554 and then switch to the new session 556.
If a free offload processor was operating according to another session (Y from 566), the offload processor can restore the previous context 568. If a free offload processor has no stored context, it can be assigned to an existing session (if possible) 570. An existing hardware schedule can be updated correspondingly 572.
Processor modules according to embodiments herein can be employed to accomplish various processing tasks. According to some embodiments, processor modules can be attached to a system memory bus to operate on network packet data. Such embodiments will now be described.
According to some embodiments, packets corresponding to a particular flow can be transported to a storage location accessible by, or included within computational unit 600. Such transportation can occur without consuming resources of a host processor module 606c connected to memory bus 616. In particular embodiments, such transport can occur without interrupting the host processor module 606c. In such an arrangement, a host processor module 606c does not have to handle incoming flows. Incoming flows can be directed to computational unit 600, which in particular embodiments can include one or more general purpose processors 608i. Such general purpose processors 608i can be capable of running code for terminating incoming flows.
In one very particular embodiment, a general purpose processor 608i can run code for terminating particular network flow session types, such as Apache video sessions, as but one example.
In addition or alternatively, a general purpose processor 608i can process metadata of a packet. In such embodiments, such metadata can include one or more fields of a header for the packet, or a header encapsulated further within the packet.
Referring still to
Conventional packet processing systems can utilize host processors for packet termination. However, due to the context switching involved in handling multiple sessions, conventional approaches require significant processing overhead for such context switching, and can incur memory access and network stack delay.
In contrast to conventional approaches, embodiments as disclosed herein can enable high speed packet termination by reducing context switch overhead of a host processor. Embodiments can provide any of the following functions: 1) offload computation tasks to one or more processors via a system memory bus, without the knowledge of the host processor, or significant host processor involvement; 2) interconnect servers in a rack or amongst racks by employing offload processors as switches; or 3) use I/O virtualization to redirect incoming packets to different offload processors.
Referring still to
According to embodiments, an I/O device 602 can write a descriptor including details of the necessary memory operation for the packet (i.e. read/write, source/destination). Such a descriptor can be assigned a virtual memory location (e.g., by an operating system of the system 601). I/O device 602 can communicate with an input output memory management unit (IOMMU) 604 which can translate virtual addresses to corresponding physical addresses. In the particular embodiment shown, a translation look-aside buffer (TLB) 604a can be used for such translation. Virtual function reads or writes data between I/O device and system memory locations can then be executed with a direct memory transfer (e.g., DMA) via a memory controller 606b of the system 601. An I/O device 602 can be connected to IOMMU 604b by a host bus 612. In one very particular embodiment, a host bus 612 can be a peripheral interconnect (PCI) type bus. IOMMU 604b can be connected to a host processing section 606 at a central processing unit I/O (CPUIO) 606a. In the embodiment shown, such a connection 664 can support a HyperTransport (HT) protocol.
In the embodiment shown, a host processing section 606 can include the CPUIO 606a, memory controller 606b, host processor module 606c and corresponding provisioning agent 606d.
In particular embodiments, a computational unit 600 can interface with the system bus 616 via standard in-line module connection, which in very particular embodiments can include a DIMM type slot. In the embodiment shown, a memory bus 616 can be a DDR3 type memory bus, however alternate embodiments can include any suitable system memory bus. Packet data can be sent by memory controller 606b to via memory bus 616 to a DMA slave interface 610a. DMA slave interface 610a can be adapted to receive encapsulated read/write instructions from a DMA write over the memory bus 616.
A hardware scheduler (608b/c/d/e/h) can perform traffic management on incoming packets by categorizing them according to flow using session metadata. Packets can be queued for output in an onboard memory (610b/608a/608m) based on session priority. When the hardware scheduler determines that a packet for a particular session is ready to be processed by the offload processor 608i, the onboard memory is signaled for a context switch to that session. Utilizing this method of prioritization, context switching overhead can be reduced, as compared to conventional approaches. That is, a hardware scheduler can handle context switching decisions and thus optimizing the performance of the downstream resource (e.g., offload processor 608i).
As noted above, in very particular embodiments, an offload processor 608i can be a “wimpy” core type processor. According to some embodiments, a host processor module 606c can include a “brawny” core type processor (e.g., an x86 or any other processor capable of handling “heavy touch” computational operations). While an I/O device 602 can be configured to trigger host processor interrupts in response to incoming packets, according to embodiments, such interrupts can be disabled, thereby reducing processing overhead for the host processor module 606c. In some very particular embodiments, an offload processor 608i can include an ARM, ARC, Tensilica, MIPS, Strong/ARM or any other processor capable of handling “light touch” operations. Preferably, an offload processor can run a general purpose operating system for executing a plurality of sessions, which can be optimized to work in conjunction with the hardware scheduler in order to reduce context switching overhead.
Referring still to
According to embodiments, multiple devices can be used to redirect traffic to specific memory addresses. So, each of the network devices operates as if it is transferring the packets to the memory location of a logical entity. However, in reality, such packets can be transferred to memory addresses where they can be handled by one or more offload processors. In particular embodiments such transfers are to physical memory addresses, thus logical entities can be removed from the processing, and a host processor can be free from such packet handling.
Accordingly, embodiments can be conceptualized as providing a memory “black box” to which specific network data can be fed. Such a memory black box can handle the data (e.g., process it) and respond back when such data is requested.
Referring still to
I/O device 602 can include, but is not limited to, peripheral component interconnect (PCI) and/or PCI express (PCIe) devices connecting with host motherboard via PCI or PCIe bus (e.g., 612). Examples of I/O devices include a network interface controller (N IC), a host bus adapter, a converged network adapter, an ATM network interface etc.
In order to provide for an abstraction scheme that allows multiple logical entities to access the same I/O device 602, the I/O device may be virtualized to provide for multiple virtual devices each of which can perform some of the functions of the physical I/O device. The IO virtualization program, according to an embodiment, can redirect traffic to different memory locations (and thus to different offload processors attached to modules on a memory bus). To achieve this an I/O device 602 (e.g., a network card) may be partitioned into several function parts; including controlling function (CF) supporting input/output virtualization (IOV) architecture (e.g., single-root IOV) and multiple virtual function (VF) interfaces. Each virtual function interface may be provided with resources during runtime for dedicated usage. Examples of the CF and VF may include the physical function and virtual functions under schemes such as Single Root I/O Virtualization or Multi-Root I/O Virtualization architecture. The CF acts as the physical resources that sets up and manages virtual resources. The CF is also capable of acting as a full-fledged IO device. The VF is responsible for providing an abstraction of a virtual device for communication with multiple logical entities/multiple memory regions.
The operating system/the hypervisor/any of the virtual machines/user code running on a host processor module 606c may be loaded with a device model, a VF driver and a driver for a CF. The device model may be used to create an emulation of a physical device for the host processor 606c to recognize each of the multiple VFs that are created. The device model may be replicated multiple times to give the impression to a VF driver (a driver that interacts with a virtual IO device) that it is interacting with a physical device of a particular type.
For example, a certain device module may be used to emulate a network adapter such as the Intel® Ethernet Converged Network Adapter (CNA) X540-T2, so that the I/O device 602 believes it is interacting with such an adapter. In such a case, each of the virtual functions may have the capability to support the functions of the above said CNA, i.e., each of the Physical Functions should be able to support such functionality. The device model and the VF driver can be run in either privileged or non-privileged modes. In some embodiments, there is no restriction with regard to who hosts/runs the code corresponding to the device model and the VF driver. The code, however, has the capability to create multiple copies of device model and VF driver so as to enable multiple copies of said I/O interface to be created.
An application or provisioning agent 606d, as part of an application/user level code running in a kernel, may create a virtual I/O address space for each VF during runtime and allocate part of the physical address space to it. For example, if an application handling the VF driver instructs it to read or write packets from or to memory addresses 0xaaaa to 0xffff, the device driver may write I/O descriptors into a descriptor queue with a head and tail pointer that are changed dynamically as queue entries are filled. The data structure may be of another type as well, including but not limited to a ring structure 602a or hash table.
The VF can read from or write data to the address location pointed to by the driver (and hence to a computational unit 600). Further, on completing the transfer of data to the address space allocated to the driver, interrupts, which are usually triggered to the host processor to handle said network packets, can be disabled. Allocating a specific I/O space to a device can include allocating said IO space a specific physical memory space occupied.
In another embodiment, the descriptor may comprise only a write operation, if the descriptor is associated with a specific data structure for handling incoming packets. Further, the descriptor for each of the entries in the incoming data structure may be constant so as to redirect all data write to a specific memory location. In an alternate embodiment, the descriptor for consecutive entries may point to consecutive entries in memory so as to direct incoming packets to consecutive memory locations.
Alternatively, said operating system may create a defined physical address space for an application supporting the VF drivers and allocate a virtual memory address space to the application or provisioning agent 606d, thereby creating a mapping for each virtual function between said virtual address and a physical address space. Said mapping between virtual memory address space and physical memory space may be stored in IOMMU tables 604a. The application performing memory reads or writes may supply virtual addresses to say virtual function, and the host processor OS may allocate a specific part of the physical memory location to such an application.
Alternatively, VF may be configured to generate requests such as read and write which may be part of a direct memory access (DMA) read or write operation, for example. The virtual addresses is be translated by the IOMMU 604b to their corresponding physical addresses and the physical addresses may be provided to the memory controller for access. That is, the IOMMU 604b may modify the memory requests sourced by the I/O devices to change the virtual address in the request to a physical address, and the memory request may be forwarded to the memory controller for memory access. The memory request may be forwarded over a bus 614. The VF may in such cases carry out a direct memory access by supplying the virtual memory address to the IOMMU 604b.
Alternatively, said application may directly code the physical address into the VF descriptors if the VF allows for it. If the VF cannot support physical addresses of the form used by the host processor 606c, an aperture with a hardware size supported by the VF device may be coded into the descriptor so that the VF is informed of the target hardware address of the device. Data that is transferred to an aperture may be mapped by a translation table to a defined physical address space in the system memory. The DMA operations may be initiated by software executed by the processors, programming the I/O devices directly or indirectly to perform the DMA operations.
Referring still to
A DMA slave module 610a can reconstruct the DMA read/write instruction from the memory R/W packet. The DMA slave module 610a may be adapted to respond to these instructions in the form of data reads/data writes to a DMA master, which could either be housed in a peripheral device, in the case of a PCIe bus, or a system DMA controller in the case of an ISA bus.
I/O data that is received by the DMA device 610a can then be queued for arbitration. Arbitration is the process of scheduling packets of different flows, such that they are provided access to available bandwidth based on a number of parameters. In general, an arbiter provides resource access to one or more requestors. If multiple requestors request access, an arbiter 610f can determine which requestor becomes the accessor and then passes data from the accessor to the resource interface, and the downstream resource can begin execution on the data. After the data has been completely transferred to a resource, and the resource has competed execution, the arbiter 610f can transfer control to a different requestor and this cycle repeats for all available requestors. In the embodiment of
Alternatively, a computation unit 600 can utilize an arbitration scheme shown in U.S. Pat. No. 7,863,283, issued to Dalal on Oct. 62, 2010, the content of which are incorporated herein by reference. Other suitable arbitration schemes known in art could be implemented in embodiments herein. Alternatively, the arbitration scheme for an embodiment can be an OpenFlow switch and an OpenFlow controller.
In the very particular embodiment of
Referring to
In some embodiments, session metadata 608d can serve as the criterion by which packets are prioritized and scheduled and as such, incoming packets can be reordered based on their session metadata. This reordering of packets can occur in one or more buffers and can modify the traffic shape of these flows. The scheduling discipline chosen for this prioritization, or traffic management (TM), can affect the traffic shape of flows and micro-flows through delay (buffering), bursting of traffic (buffering and bursting), smoothing of traffic (buffering and rate-limiting flows), dropping traffic (choosing data to discard so as to avoid exhausting the buffer), delay jitter (temporally shifting cells of a flow by different amounts) and by not admitting a connection (e.g., cannot simultaneously guarantee existing service (SLAs) with an additional flow's SLA).
According to embodiments, computational unit 600 can serve as part of a switch fabric, and provide traffic management with depth-limited output queues, the access to which is arbitrated by a scheduling circuit 608b/n. Such output queues are managed using a scheduling discipline to provide traffic management for incoming flows. The session flows queued in each of these queues can be sent out through an output port to a downstream network element.
It is noted that some conventional traffic management circuits do not take into the account the handling and management of data by downstream elements except for meeting the SLA agreements it already has with said downstream elements. In contrast, according to embodiments, a scheduler circuit 608b/n can allocate a priority to each of the output queues and carry out reordering of incoming packets to maintain persistence of session flows in these queues. A scheduler circuit 608b/n can be used to control the scheduling of each of these persistent sessions into a general purpose operating system (OS) 608j, executed on an offload processor 608i. Packets of a particular session flow, as defined above, can belong to a particular queue. The scheduler circuit 608b/n may control the prioritization of these queues such that they are arbitrated for handling by a general purpose (GP) processing resource (e.g., offload processor 608i) located downstream. An OS 608j running on a downstream processor 608i can allocate execution resources such as processor cycles and memory to a particular queue it is currently handling. The OS 608j may further allocate a thread or a group of threads for that particular queue, so that it is handled distinctly by the general purpose processing element 608i as a separate entity. Thus, in some embodiments there can be multiple sessions running on a GP processing resource, each handling data from a particular session flow resident in a queue established by the scheduler circuit, to tightly integrate the scheduler and the downstream resource (e.g., 608i). This can bring about persistence of session information across the traffic management and scheduling circuit and the general purpose processing resource 608j.
Dedicated computing resources (e.g., 608i), memory space and session context information for each of the sessions can provide a way of handling, processing and/or terminating each of the session flows at the general purpose processor 608i. The scheduler circuit 608b/n can exploit this functionality of the execution resource to queue session flows for scheduling downstream. For example, the scheduler circuit 608b/n can be informed of the state of the execution resource(s) (e.g., 608i), the current session that is run on the execution resource; the memory space allocated to it, the location of the session context in the processor cache.
According to embodiments, a scheduler circuit 608b/n can further include switching circuits to change execution resources from one state to another. The scheduler circuit 608b/n can use such a capability to arbitrate between the queues that are ready to be switched into the downstream execution resource. Further, the downstream execution resource can be optimized to reduce the penalty and overhead associated with context switch between resources. This is further exploited by the scheduler circuit 608b/n to carry out seamless switching between queues, and consequently their execution as different sessions by the execution resource.
A scheduler circuit 608b/n according to embodiments can schedule different sessions on a downstream processing resource, wherein the two are operated in coordination to reduce the overhead during context switches. An important factor to decreasing the latency of services and engineering computational availability can be hardware context switching synchronized with network queuing. In embodiments, when a queue is selected by a traffic manager, a pipeline coordinates swapping in of the cache (e.g., L2 cache) of the corresponding resource and transfers the reassembled I/O data into the memory space of the executing process. In certain cases, no packets are pending in the queue, but computation is still pending to service previous packets. Once this process makes a memory reference outside of the data swapped, the scheduler circuit can enable queued data from an I/O device 602 to continue scheduling the thread.
In some embodiments, to provide fair queuing to a process not having data, a maximum context size can be assumed as data processed. In this way, a queue can be provisioned as the greater of computational resource and network bandwidth resource. As but one very particular example, a computation resource can be an ARM A9 processor running at 800 MHz, while a network bandwidth can be 3 Gbps of bandwidth. Given the lopsided nature of this ratio, embodiments can utilize computation having many parallel sessions (such that the hardware's prefetching of session-specific data offloads a large portion of the host processor load) and having minimal general purpose processing of data.
Accordingly, in some embodiments, a scheduler circuit 608b/n can be conceptualized as arbitrating, not between outgoing queues at line rate speeds, but arbitrating between terminated sessions at very high speeds. The stickiness of sessions across a pipeline of stages, including a general purpose OS, can be a scheduler circuit optimizing any or all such stages of such a pipeline.
Alternatively, a scheduling scheme can be used as shown in U.S. Pat. No. 7,760,765 issued to Dalal on Jul. 20, 2010, incorporated herein by reference. This scheme can be useful when it is desirable to rate limit the flows for preventing the downstream congestion of another resource specific to the over-selected flow, or for enforcing service contracts for particular flows. Embodiments can include arbitration scheme that allows for service contracts of downstream resources, such as general purpose OS that can be enforced seamlessly.
Referring still to
In some embodiments, offload processors (e.g., 608i) can be general purpose processing units capable of handling packets of different application or transport sessions. Such offload processors can be low power processors capable of executing general purpose instructions. The offload processors could be any suitable processor, including but not limited to: ARM, ARC, Tensilica, MIPS, StrongARM or any other processor that serves the functions described herein. The offload processors have general purpose OS running on them, wherein the general purpose OS is optimized to reduce the penalty associated with context switching between different threads or group of threads.
In contrast, context switches on host processors can be computationally intensive processes that require the register save area, process context in the cache and TLB entries to be restored if they are invalidated or overwritten. Instruction Cache misses in host processing systems can lead to pipeline stalls and data cache misses lead to operation stall and such cache misses reduce processor efficiency and increase processor overhead.
According to embodiments, an OS 608j running on the offload processors 608i in association with a scheduler circuit, can operate together to reduce the context switch overhead incurred between different processing entities running on it. Embodiments can include a cooperative mechanism between a scheduler circuit and the OS on the offload processor 608i, wherein the OS sets up session context to be physically contiguous (physically colored allocator for session heap and stack) in the cache; then communicates the session color, size, and starting physical address to the scheduler circuit upon session initialization. During an actual context switch, a scheduler circuit can identify the session context in the cache by using these parameters and initiate a bulk transfer of these contents to an external low latency memory. In addition, the scheduler circuit can manage the prefetch of the old session if its context was saved to a local memory 608g. In particular embodiments, a local memory 608g can be low latency memory, such as a reduced latency dynamic random access memory (RLDRAM), as but one very particular embodiment. Thus, in embodiments, session context can be identified distinctly in the cache.
In some embodiments, context size can be limited to ensure fast switching speeds. In addition or alternatively, embodiments can include a bulk transfer mechanism to transfer out session context to a local memory 608g. The cache contents stored therein can then be retrieved and prefetched during context switch back to a previous session. Different context session data can be tagged and/or identified within the local memory 608m for fast retrieval. As noted above, context stored by one offload processor may be recalled by a different offload processor.
In the very particular embodiment of
An IOMMU 621 can map received data to physical addresses of a system address space. DMA master 625 can transmit such data to such memory addresses by operation of a memory controller 622. Memory controller 622 can execute DRAM transfers over a memory bus with a DMA Slave 627. Upon receiving transferred I/O data, a hardware scheduler 623 can schedule processing of such data with an offload processor 624. In some embodiments, a type of processing can be indicated by metadata within the I/O data. Further, in some embodiments such data can be stored in an Onboard Memory 629. According to instructions from hardware scheduler 623, one or more offload processors 624 can execute computing functions in response to the I/O data. In some embodiments, such computing functions can operate on the I/O data, and such data can be subsequently read out on memory bus via a read request processed by DMA Slave 627.
It should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.
It is also understood that the embodiments of the invention may be practiced in the absence of an element and/or step not specifically disclosed. That is, an inventive feature of the invention may be elimination of an element.
Accordingly, while the various aspects of the particular embodiments set forth herein have been described in detail, the present invention could be subject to various changes, substitutions, and alterations without departing from the spirit and scope of the invention.
This application claims the benefit of U.S. Provisional Patent Applications 61/650,373 filed May 22, 2012, 61/753,892 filed on Jan. 17, 2013, 61/753,895 filed on Jan. 17, 2013, 61/753,899 filed on Jan. 17, 2013, 61/753,901 filed on Jan. 17, 2013, 61/753,903 filed on Jan. 17, 2013, 61/753,904 filed on Jan. 17, 2013, 61/753,906 filed on Jan. 17, 2013, 61/753,907 filed on Jan. 17, 2013, and 61/753,910 filed on Jan. 17, 2013, the contents all of which are incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 61650373 | May 2012 | US | |
| 61753892 | Jan 2013 | US | |
| 61753895 | Jan 2013 | US | |
| 61753899 | Jan 2013 | US | |
| 61753901 | Jan 2013 | US | |
| 61753903 | Jan 2013 | US | |
| 61753904 | Jan 2013 | US | |
| 61753906 | Jan 2013 | US | |
| 61753907 | Jan 2013 | US | |
| 61753910 | Jan 2013 | US |
