Evaluating Network Processing Efficiency with Processor Partitioning and Asynchronous I/O
Tim Brecht, G. (John) Janakiraman, Brian Lynn, Vikram Saletore, Yoshio Turner Enterprise Software and Systems Laboratory HP Laboratories Palo Alto HPL-2005-211(R.1) April 14, 2006*
network Applications requiring high-speed TCP/IP processing can easily saturate processing, a modern server. We and others have previously suggested alleviating asynchronous I/O, this problem in multiprocessor environments by dedicating a subset of the TCP/IP, multi-core processors to perform network packet processing. The remaining processors processors perform only application computation, thus eliminating contention between these functions for processor resources. Applications interact with packet processing engines (PPEs) using an asynchronous I/O (AIO) programming interface which bypasses the operating system. A key attraction of this overall approach is that it exploits the architectural trend toward greater thread-level parallelism in future systems based on multi-core processors. In this paper, we conduct a detailed experimental performance analysis comparing this approach to a best-practice configured Linux baseline system.
* Internal Accession Date Only Published in and presented at EuroSys2006, 18-21 April 2006, Leuven, Belgium Approved for External Publication © Copyright 2006 ACM Evaluating Network Processing Efficiency with Processor Partitioning and Asynchronous I/O
Tim Brecht‡ G. (John) Janakiraman§ Brian Lynn§ Vikram Saletore∗∗ Yoshio Turner§
§Hewlett Packard Laboratories ∗∗ Intel® Corporation ‡University of Waterloo
ABSTRACT Categories and Subject Descriptors Applications requiring high-speed TCP/IP processing can D.4.4 [Operating Systems]: Communications Manage- easily saturate a modern server. We and others have pre- ment—Network communication; C.4 [Performance of viously suggested alleviating this problem in multiproces- Systems]: Design Studies; C.5.5 [Computer System Im- sor environments by dedicating a subset of the processors plementation]: Servers to perform network packet processing. The remaining pro- cessors perform only application computation, thus elimi- General Terms nating contention between these functions for processor re- Performance, Design, Experimentation sources. Applications interact with packet processing en- gines (PPEs) using an asynchronous I/O (AIO) program- ming interface which bypasses the operating system. A key Keywords attraction of this overall approach is that it exploits the ar- Network Processing, Asynchronous I/O, TCP/IP chitectural trend toward greater thread-level parallelism in future systems based on multi-core processors. In this pa- 1. INTRODUCTION per, we conduct a detailed experimental performance anal- Network protocol processing can saturate servers when ysis comparing this approach to a best-practice configured running high-speed TCP/IP-based applications. High over- Linux baseline system. head for packet processing can leave few CPU cycles avail- We have built a prototype system implementing this ar- able for actual application processing. This problem is wors- chitecture, ETA+AIO (Embedded Transport Acceleration ening as servers deploy higher bandwidth 10 GigE interfaces. with Asynchronous I/O), and ported a high-performance One solution that has been proposed is to offload TCP/IP web-server to the AIO interface. Although the prototype processing from the host CPUs to the network interface to uses modern single-core CPUs instead of future multi-core accelerate network processing and free host cycles for ap- CPUs, an analysis of its performance can reveal important plication processing. However, prior TCP offload investi- properties of this approach. Our experiments show that gations [9, 46, 47, 33, 21] have not demonstrated such im- the ETA+AIO prototype has a modest advantage over the provements and point to the limited capabilities of the TCP baseline Linux system in packet processing efficiency, con- Offload Engine (TOE) hardware. While future TOE designs suming fewer CPU cycles to sustain the same throughput. will likely show improvements, the processing elements in This efficiency advantage enables the ETA+AIO prototype TOEs are likely to always be behind the performance curve to achieve higher peak throughput than the baseline system, of mainstream processors. Furthermore, memory limitations but only for workloads where the mix of packet processing on TOE devices can force them to rely on host support in and application processing approximately matches the allo- high load scenarios, degrading performance. cation of CPUs in the ETA+AIO system thereby enabling Several evolutionary trends in server hardware and net- high utilization of all the CPUs. Detailed analysis shows working software stacks have renewed focus on improving that the efficiency advantage of the ETA+AIO prototype, the packet processing efficiency of servers without resort- which uses one PPE CPU, comes from avoiding multipro- ing to wholesale TCP offload [50, 42, 43, 41, 12]. The cessing overheads in packet processing, lower overhead of higher degree of parallelism enabled by multi-core, multi- our AIO interface compared to standard sockets, and re- threaded processors is a good fit for concurrently process- duced cache misses due to processor partitioning. ing multiple network streams. Increasing cache sizes and shared caches on multi-core chips provide greater poten- tial to hide memory latency by transferring data between processors through the caches (e.g., between the applica- Permission to make digital or hard copies of all or part of this work for tion and the network stack). Memory bandwidth and I/O personal or classroom use is granted without fee provided that copies are bandwidth will scale with the number of processing ele- not made or distributed for profit or commercial advantage and that copies ments as server designs transition to high-bandwidth point- bear this notice and the full citation on the first page. To copy otherwise, to to-point links (from multi-drop shared buses) for memory republish, to post on servers or to redistribute to lists, requires prior specific and I/O [11]. Furthermore, memory controller interfaces permission and/or a fee. EuroSys'06, April 18–21, 2006, Leuven, Belgium. and network interfaces will be integrated much closer to pro-
Copyright 2006 ACM 1-59593-322-0/06/0004 ...° 5.00. cessor cores reducing memory and I/O overheads and bottle- necks. Concurrent with these hardware developments, the ing event notifications. ETA’s polling-based dedicated PPE socket/TCP/IP network stack is evolving [4] to adopt con- architecture avoids interrupt related overheads, for exam- cepts such as OS-bypass and asynchronous I/O from APIs ple by substituting softirq mechanisms with lighter-weight such as VIA [17] and InfiniBand [26] to reduce operating sys- in-line function calls, and it results in reduced cache misses tem overhead and increase I/O concurrency. Our research is by eliminating cache conflicts between the application code aimed at leveraging these trends to support scalable network and the network stack. performance on standard server platforms. Our second main contribution is to provide a detailed de- In this direction, we and others [50, 42, 43, 41] have sug- scription of the changes required and issues that arose when gested that network packet processing efficiency can be im- modifying the event-driven userver to take full advantage of proved by dedicating a subset of the server’s processors for the asynchronous socket I/O model. Our experience with network processing and by using asynchronous I/O for com- extending the userver to use the AIO API illustrates sev- munication between the network processing engine and the eral new aspects that should be factored in when developing application. In our architecture, the Embedded Trans- AIO-based applications. In particular, the use of an AIO port Acceleration (ETA) [42, 50] component (developed model necessitates additional steps for registering and de- at Intel® Labs) dedicates (“sequesters”) one or more pro- registering (and, therefore, managing) buffer memory, sim- cessors or hardware threads in the server to perform all net- plifies the application by eliminating the need to handle par- work processing. These dedicated Packet Processing En- tially completed operations, exposes new considerations in gines (PPEs) avoid context switches and cache conflicts the sequencing of the application’s socket operations, and with application processes, and they avoid costly interrupts enables applications to process events and issue operations by polling applications and network interfaces. PPEs can using application-specific policies to improve resource man- poll efficiently since they are fully integrated in the sys- agement and performance. In addition, given the similarity tem’s cache coherence domain. ETA also exposes VIA- of our AIO API to the Sockets Extension API [4] being de- style [17] user-level communication to applications, reducing veloped in the industry, our implementation of AIO over data copies and bypassing the operating system for most I/O ETA is potentially useful as an example implementation for operations [26, 3]. The second component of our architec- the Sockets Extension API. ture exposes Asynchronous I/O (AIO) based socket se- The remainder of this paper is organized as follows. We mantics to applications [7, 6, 4, 23]. The APIs support asyn- discuss related work in Section 2. Section 3 provides an chronous versions of traditional socket operations. Applica- overview of the ETA+AIO architecture, followed by a de- tions issue operations without being blocked and without tailed discussion of the ETA implementation in Section 4 first verifying socket descriptor status. Applications receive and the AIO API implementation in Section 5. Section 6 asynchronous events that signify the completion of previ- describes the architecture of our userver application and its ously issued I/O operations. The AIO model allows applica- modification to use the AIO API. Section 7 discusses the tions to sustain concurrent I/O operations without the over- results from our performance evaluation of ETA+AIO. Po- head of multiple software threads. The queues of operations tential architectural extensions are discussed in Section 8, and events between the application and the packet process- and we conclude in Section 9. ing allow these two functions to independently speed up or slow down with respect to each other, enabling greater con- 2. BACKGROUND AND RELATED WORK currency between them. The combined ETA+AIO architec- A network server application can be implemented us- ture enables the development of highly concurrent, low over- ing a multithreading programming model, an event-driven head, event-based networking applications. Event-based ap- programming model, or a combination thereof [39]. The plications are structured as state machines in which a state ETA+AIO architecture is well suited to the more efficient transition occurs when the application processes an event event-driven model, which is free of the thread scheduling (e.g., when the OS or an I/O device notifies the application and context switching overheads inherent to multithreading. that an outstanding operation has completed) [51]. With the event-driven model an application consists of a sin- This paper makes two primary contributions. First, it gle execution thread per CPU. To avoid pausing the single provides the first rigorous analysis of this approach based thread for extended durations, the thread must use either on processor partitioning and asynchronous I/O, and iden- non-blocking or asynchronous I/O (AIO) to perform I/O op- tifies its strengths, weaknesses, and opportunities. We have erations. The standard network sockets interface supports ported an open source web server, userver [14], to a pro- non-blocking I/O operations which execute synchronously totype implementation of the ETA+AIO architecture and with the application and return prematurely if they can- compared its performance against performance on a baseline not complete without blocking [49]. Applications use an Linux system configured using best practices. Our experi- event notification mechanism, such as Unix select or poll mental results show that processor partitioning combined or Linux epoll [32, 38], to detect changes in socket state that with AIO can improve network processing efficiencies over indicate which non-blocking operations could make progress the best Linux configuration, but these benefits are small if issued. in magnitude for the prototype system. Our analysis shows In contrast to non-blocking I/O, with AIO an application that the efficiency advantages of the prototype system re- issues non-blocking calls which post operations that execute sult primarily from instruction path length improvements to completion asynchronously to the application. When the through the use of AIO and a polling architecture, and to operations eventually complete, the application is notified, a small degree from reduced cache misses. The AIO API usually through an event queue mechanism. AIO thus elim- allows the application to interface with the PPE directly inates the partially completed operations which can burden through shared memory, bypassing operating system over- applications that use non-blocking I/O. There is a growing heads associated with issuing socket operations and receiv- trend toward enabling applications to use AIO in addition to non-blocking I/O. For example, Lazy AIO has recently interface to the NIC, OS device drivers and the protocol been proposed as a general OS mechanism for automatically stack software must be designed or modified to take advan- converting any system call that blocks into an asynchronous tage of these capabilities. The ETA architecture can benefit call [18]. With Lazy AIO, calls that do not have to block ex- as much as conventional systems from NIC offloading capa- ecute to completion synchronously to the application (sim- bilities since the ETA architecture makes only slight modi- ilarly to non-blocking I/O), whereas calls that would have fications to a standard TCP/IP stack implementation. to block are transformed automatically into asynchronous Although offloading selected functions has proved success- operations, which require completion event generation. The ful, so far there is only limited use of TCP Offload En- more specialized POSIX AIO API supports a set of asyn- gine (TOE) NICs, which offload the entire TCP/IP pro- chronous read and write operations and uses POSIX real- cessing for some or all packets to the NIC. TOEs typically time signals to provide an event queue for notifying applica- rely on firmware and specialized hardware implementations, tions of operation completion [7]. Microsoft Windows pro- which are more difficult to upgrade and customize than host vides extensive support for AIO, with notification provided software-based implementations. TOEs have not yet demon- through OS event queues called completion ports [23]. The strated significant performance benefits [9, 46, 47, 33], pos- Open Group, which defines Unix standards, has recently ap- sibly because the current scarcity of NIC hardware resources proved the Extended Sockets API, which provides extensive limits scalability, rendering a TOE better suited for support- AIO capabilities for network sockets [4]. Extended Sockets ing a few long-lived TCP connections than for workloads differs from prior asynchronous sockets mechanisms by pro- with a large number of short-lived connections (e.g., web viding OS bypass primitives inspired by previous work such server workloads) [33]. In recent work, Freimuth et al [21] as VIA [17]. Specifically, primitives for memory registration propose a TOE design to minimize bus crossings, data and for shared memory work queues and event queues enable copies, cache misses, and interrupts, which they argue limit applications to post operations and receive completion noti- the scalability of current systems. Using a purely software- fication without going through the OS kernel. In this paper, based emulation environment, they demonstrate that their we use an AIO API that provides socket-like primitives and TOE design reduces I/O bus utilization (they plan to evalu- OS bypass capabilities very similar to Extended Sockets. In ate other performance aspects in future work). Hence, they Section 6 we present our experiences with using this API to cannot yet assess the overall performance benefits of this implement an open source web server application. approach. In this paper, we take a different evaluation ap- To support applications, the underlying system performs proach. We evaluate a real multiprocessor server implemen- TCP/IP packet processing. The high cost of this processing tation of the ETA+AIO architecture and measure network has been a long-standing concern. In 1989, Clark et al [15] throughput and CPU usage. We present a detailed analy- argued that the TCP protocol itself can be implemented sis of these results which quantifies the impact of different efficiently in software, but operations like buffer manage- elements of the ETA+AIO architecture on microarchitec- ment, connection structure lookup, and interrupt handling, ture performance attributes including instruction execution which would all be needed with any transport layer pro- rates, cache misses, and interrupt processing overhead. tocol are often expensive and limit performance. Kay and At the microprocessor level, the growing challenges of Pasquale [29] later reported the high cost of data touch- power density and interconnect delay are limiting further ing operations (e.g., copies and checksum computations), increases in single-core processor performance. Thus, the and Mogul and Ramakrishnan [34] showed that under high emerging design trend is to use increasing transistor den- traffic loads interrupt processing could easily overwhelm a sity to increase the integration of functions on a chip and to server. These and related studies [30, 20, 19] have proposed implement multi-core processors. As multi-core processors various techniques to improve packet processing efficiency. decrease the relative cost of individual cores and provide Recent OS kernels provide features that can reduce net- mechanisms for fast inter-core communication, it becomes work processing overhead. The “zero-copy” sendfile sys- more attractive to dedicate some cores to packet processing, tem call enables data transfer between file descriptors with- as in the ETA+AIO architecture. In addition, this approach out requiring the data to be copied through user space is complementary to proposals for placing network inter- buffers. Processor affinity for interrupts reduces device face hardware close to or even integrated onto the processor driver contention for network hardware and kernel data chip [12], and techniques for intelligently transferring data structures [19]. Software-based interrupt moderation (e.g., directly between network hardware and CPU caches [12, 25]. NAPI [45]) can help reduce the overhead of interrupt pro- Previous studies of an earlier version of our ETA+AIO cessing under high loads. Many of these features are not use- prototype indicate that it improves performance for sim- ful in the ETA+AIO architecture, which bypasses the kernel ple microbenchmarks [42, 44]. In contrast, our evaluation for most data transfer operations. However, the ETA+AIO vehicle is a full-fledged event-driven web server application architecture provides similar benefits, avoiding copies on the driven by a SPECweb99-like workload [48]. The web server transmit path like sendfile, and eliminating the overhead application makes full use of sendfile, non-blocking I/O of network device interrupts by using a polling interface. and epoll, and an aggressive connection acceptance strat- To reduce heavy loads on host CPUs, recent network in- egy. terface card (NIC) designs provide some degree of offload- An earlier (1998) approach that also dedicated CPUs ing, the ability to execute some packet processing operations to device processing was the AsyMOS [36] and Piglet [37] that previously had to execute on the CPU. In particular, project. The mechanisms proposed in that project appear modern mainstream NICs (e.g., Intel ® PRO/1000 gigabit to provide more generality than ETA, allowing for example Ethernet) can perform TCP/IP checksums and segmenta- the ability to download user code to the dedicated device tion, and provide programmable timers used for interrupt processors. However, the published evaluations include only moderation [27]. Because offloading changes the software device driver code on the device processors, while TCP is left for the application CPUs. In addition, only a very prelim- inary performance analysis is presented, and of course the analysis is based on the relatively unsophisticated hardware and OS features of that time period. TCP Servers [41], a more recent project similar to ETA, has examined the impact of sequestering CPUs for dedi- cated TCP processing. The TCP Servers project provides an AIO API that supports zero-copy data transfers [40], but this AIO API is implemented only for transfers between dif- ferent nodes of a cluster interconnected by a system-area network. On a multiprocessor platform, the implementa- tion of TCP Servers provides neither zero-copy transfers nor AIO for interactions between applications and the ded- icated packet processing CPUs. In contrast, our prototype provides these features in a multiprocessor implementation. The TCP Servers study finds that offloading TCP/IP pro- cessing can improve server throughput by up to 30%, that noticeable benefits are obtained by using network interface polling rather than interrupts, and that substantial com- Figure 1: DUSI/ETA PPE Software Architecture puting resources are required for complete offloading. In addition, the authors note that server performance would further benefit from a scheme for dynamically adjusting the semantics to applications with asynchronous versions of lis- allocation of CPUs for application and network processing. ten, accept, send, receive, etc. Unlike both the TCP Servers work and the previous Figure 1 depicts the architectural components and par- ETA+AIO investigations, in this paper we explicitly en- titioning between the “sequestered” CPUs and the “host” sure that we compare the ETA+AIO prototype against a CPUs. The Packet Processing Engine (PPE) is a kernel best-practice configured standard Linux system with inter- thread running on the sequestered CPU, and takes no part rupt and application processor affinity, network interface in user applications. The Direct User Adaptation Layer interrupt moderation, and NIC checksum offloading. Our Provider Library (DUSI Library) implements the AIO func- findings are significantly different from these previous stud- tions and is linked with applications executing on the host ies. We observe smaller benefits from partitioning since we CPUs. Applications and the PPE interact through queues compare against a strong baseline system that benefits, for created in cache coherent shared system memory. Queu- example, from transmit-side copy-avoidance and interrupt ing and dequeing operations and events are extremely fast moderation. We characterize the remaining benefits of the lock-free operations requiring only a few instructions and no ETA+AIO architecture, which include higher efficiency of kernel intervention. Finally, a Kernel Agent (KA) is used the AIO API compared to sockets and improved caching for those operations for which the PPE requires Linux kernel behavior. assistance (for example, pinning data buffers in memory). Finally, Jacobson and Felderman [28] very recently pro- Applications establish communication with the ETA PPE posed techniques for speeding up network processing by us- by creating a User Adaptation Layer (UAL). The UAL ing lock-free circular buffers in the network stack instead houses all queuing structures shared between an application of traditional linked lists of socket buffer structures, and and the PPE. To initiate TCP/IP communication, an ap- also by performing TCP processing in a user-level library plication creates a Direct Transport Interface (DTI) within linked with the application. Since ETA uses the standard the UAL, analogous to creating a traditional BSD socket. A TCP stack, the benefits of changing the stack implementa- DTI contains or references all queuing structures associated tion to use circular buffers would likely accrue to both ETA with a TCP socket [50, 44]. The UAL and DTIs are created and the standard system. However, running the stack in using synchronous operations. Subsequently, the applica- a user-level library on the same CPU as the application is tion can issue socket operations through the DTI queues contrary to ETA’s use of processor partitioning, and further and receive completion events asynchronously. study is needed to evaluate the tradeoffs between these op- The PPE executes a polling loop that continuously queries posing approaches. For example, while partitioning reduces NIC descriptors and ETA queues. Since all NIC descriptors contention for CPU resources between network processing and ETA queues are accessed through shared cache-coherent and application processing, some functions (e.g., copying system memory, polling is performed directly from cache received packet data payloads from kernel memory to user- and has no effect on the memory subsystem or front-side level memory) are probably more cache-friendly when per- bus. A memory access occurs only when a memory location formed on the same CPU as the application. has been updated by either a NIC or the DUSI Library [42]. Another benefit of polling is that the PPE avoids incur- 3. ARCHITECTURE OVERVIEW ring interrupts. The PPE uses a modified Ethernet driver that allows it to perform NIC polling, and it incorporates Our architecture dedicates one or more processors or hard- a TCP/IP stack that is a slightly modified version of the ware threads of a server to perform all TCP/IP protocol pro- mainstream Linux TCP/IP stack. cessing. Applications interface to the ETA TCP/IP stack through an API called the Direct User Sockets Interface (DUSI). DUSI provides an asynchronous interface similar 4. ETA ARCHITECTURE to the Sockets Extension API [4]. It presents familiar socket In the following subsections we describe the queue struc- tures used in the Embedded Transport Acceleration (ETA) PPEPPE PollingPolling Loop Loop architecture and the operation of the PPE thread. Select NIC: Select a NIC to service in 1. Select NIC: Select a NIC Interface to Service in 4.1 ETA Queues thisthis looploop iteration iteration Each application has one instance of a UAL which con- Poll AQ: Process at most 1 operation 2. Poll AQ: Process at most 1 operation from the tains (see Figure 1) one Doorbell Queue (DbQ), one or more Admin.from the AdminQueue. Queue Event Queues (EvQs), and, for each DTI, a pair of Trans- mit and Receive descriptor queues (TX and RX). Memory Poll DbQ: Process at most 1 operation TCP/ 3. PollDbQ: Process At Most 1 operation from eachIP for these queuing structures is pinned and mapped into both Doorbellfrom each DoorbellQueue Queuefor any new work the user and kernel virtual address spaces to permit access Poll RX RX: :Poll Poll NICNIC driver driver and and process process at by both the DUSI Library and the PPE. The DUSI Library 4. mostat mostNRXN valid valid RX packets packets posts to the Doorbell Queue to alert the PPE whenever the application initiates an operation on any of its DTIs. This PollPoll TX TX: :Process Poll NIC driver a TX to packet reclaim TX& poll NIC driver to enables the PPE to discover application-initiated operations 5. reclaimdescriptors TX descriptor by polling only the DbQ instead of polling each of the queues of several DTIs. The application creates Event Queues in the UAL for use by the PPE to post events notifying the ap- plication of the completion of previously issued operations. Figure 2: PPE Polling Loop To wait for events, applications can either poll the EvQs or request notification through the OS signal mechanism. A DTI is associated with each instance of a socket sion that was initiated in some previous execution of Step 3. (whether it is an unbound or listening socket, or the end- This occurs in Step 4 when an ACK is received that opens point of a TCP stream). When an application initiates a the TCP window, allowing the blocked transmission to re- send (receive) operation on a DTI, pointers to the applica- sume. A simple scheduling policy that we have found effec- tion’s send (read) buffers are posted by the DUSI Library tive is to poll the NICs in a round-robin fashion, one NIC to the DTI’s TX (RX) descriptor queue (the DUSI Library per loop iteration, and to dequeue at most one operation also posts to the DbQ as mentioned above). When an appli- from each DbQ in each iteration. cation creates a DTI, it can bind the TX and RX queues of When using a single NIC and running one DUSI applica- the DTI to any EvQ within the UAL. This flexibility allows tion on a 2.8GHz Xeonç server, an unproductive iteration the application to combine event notifications for operations through our prototype’s PPE loop – where all queues are associated with several DTIs into a smaller number of EvQs, empty and the NIC has no packets – on average takes only reducing the number of EvQs it must poll. 152 clock cycles (∼55ns). We have found that when the In addition to the UAL queues, ETA includes the Admin- PPE has ample CPU cycles available to handle the load, the istrative Queue (AQ) and the Interrupt Queue (IQ) through choice of scheduling policy has almost no effect on perfor- which the Kernel Agent and the PPE communicate. To per- mance; the PPE achieves a fair balance between application form synchronous operations, the DUSI library invokes an and NIC processing since the queues tend not to have per- ioctl system call to schedule the Kernel Agent, which then sistent backlogs and the PPE is work-conserving (the cost queues a request to the AQ. The PPE reads requests from of polling an empty DbQ or an empty NIC is minimal). the AQ and uses the IQ to notify the Kernel Agent of the Only when the PPE starts to saturate the CPU does it completion of AQ requests and to trigger the Kernel Agent matter how effectively the scheduling policy allocates PPE to deliver signals requested by the application. The PPE CPU cycles for polling the NICs versus polling the applica- posts an event to the IQ and then generates an Interpro- tion DbQs. In this operating region, queues are longer and cessor Interrupt (IPI) for the host CPU to cause the Kernel should be drained at appropriate rates. Allocating too few Agent to be scheduled. cycles for handling DbQ entries would cause the DbQs to become unacceptably long, delaying the processing of appli- 4.2 PPE Polling Loop cation requests. Conversely, devoting more cycles to han- The PPE’s goals include ensuring that: NICs do not drop dling DbQ entries would leave fewer cycles for processing packets, NICs are never idle when there is data to be trans- network traffic. Thus, it may be beneficial to dynamically mitted, and latency is minimized for all application opera- adjust resource allocations to optimize the handling of dif- tions. This requires a balance between how aggressively the ferent workloads. PPE takes on new operations posted by applications and how often it services NICs. Our prototype PPE uses the algorithm shown in Figure 2. 5. ASYNCHRONOUS I/O (AIO) Within this loop the TCP/IP stack can be invoked in several Our prototype implements an asynchronous interface, places. The PPE contains a Linux 2.4.16 TCP/IP protocol DUSI, which allows applications to execute unimpeded while stack that includes minor modifications for it to interface to networking operations are being performed. Before a DUSI the PPE queuing mechanisms. Whenever the PPE thread application can send and receive data over TCP/IP, it must finds that a NIC has received a packet (Step 4), it invokes first call the synchronous function Dusi Open Ual to create the inbound TCP/IP stack to service the packet. When the a User Adaptation Layer and initialize application-specific PPE dequeues an application’s send operation from the DbQ data structures. In creating a UAL, an application must (Step 3), it invokes the outbound TCP/IP stack to generate specify the depth of the Doorbell Queue and the maxi- and send packets to the network. The PPE can also invoke mum number of DTIs that will be created. As with all the outbound TCP/IP stack to resume a blocked transmis- synchronous DUSI functions, creating a UAL interacts with the ETA Kernel Agent thread rather than directly with the sions may need to occur from that application buffer, ETA PPE. This provides access to kernel functions, such as for does not generate a send completion event until the remote pinning memory and translating user virtual addresses to TCP has acknowledged all of the packets. An AIO inter- kernel virtual addresses, and allows slower operations to be face lends itself nicely to sending from an application buffer offloaded from the PPE. since the application is never impeded on the send and, in An application is responsible for creating the Event contrast to BSD sockets, there is never a need to indicate Queues on which it receives notification of completed oper- partial success. ations. When an application creates a DTI socket, it asso- For inbound data, the PPE must copy data from the host ciates two EvQs with the DTI: a receive EvQ (RX EvQ) and NIC buffers into the application’s buffer. If a receive is a transmission EvQ (TX EvQ). The RX EvQ is used by the posted at the time that the PPE polls the NIC, then the application for receiving notification of when inbound opera- PPE is able to immediately copy the data to the applica- tions have completed (e.g., receives, accepts). The TX EvQ tion’s buffer, which can result in reduced latency for receives. is associated with outbound operations (e.g., send, shut- We allow an application to have multiple receives posted to downs, application initiated connections). DUSI does not a DTI so that packets can be passed to the application as put constraints on which event queues may be associated soon as the PPE detects them. with DTIs. For example, it is permissible for a DTI to use DUSI provides several mechanisms for applications to de- a single EvQ as both the RX and TX EvQs; and EvQs may termine when an operation has completed. There are very be shared amongst multiple DTIs. efficient functions for polling EvQs, dequeuing events, and To establish a TCP connection an application must first determining the EvQ event depth. At times, an applica- create the DTI socket to be associated with the stream. If tion may have operations outstanding but can do no further the application is the listener, then the application must work until one of the operations is completed. DUSI pro- also create the listen DTI socket and bind it to a TCP port vides functions that allow an application to block on a single address. In contrast to BSD sockets, where an accept opera- queue, but DUSI currently relies on the Linux user signal tion returns the TCP stream socket descriptor upon comple- mechanism to block on multiple EvQs. A function is pro- tion, a DUSI application first creates the DTI stream (child) vided for associating a signal with an EvQ (the same signal socket and then passes it, along with the DTI listen socket, can be assigned to multiple EvQs). If the application wants as input parameters to the Dusi Accept function. This per- to sleep until an event arrives, it arms the corresponding mits the application to initiate a receive on the TCP stream signal(s) and notifies DUSI to raise a signal when any of the before an accept operation has been posted. The sequence specified EvQs transitions from being empty to not empty. ensures that an application data buffer will be available to the PPE for any data immediately following the TCP SYN. 6. WEB SERVER APPLICATION To send data an application calls Dusi Send with a pointer To investigate the benefits of using ETA+AIO for network to the source data and the data’s length. The DUSI library intensive workloads, we have adapted a web server applica- writes the information to the DTI’s TX Descriptor Queue, tion to use the DUSI AIO API. A web server is a widely used and then notifies the PPE by posting to the DbQ. Similarly, and representative example of a networking application that the application initiates a read by calling Dusi Recv, which exerts high demands on system resources as a result of han- results in an event being queued to an RxQ followed by dling large numbers of simultaneous connections. the PPE being notified via the DbQ. Vectored sends and Nearly all network server applications follow a similar se- receives, specifying multiple data locations, are supported. ries of steps to handle each client connection. The server By writing to an asynchronous interface an application can receives a client request on the connection, processes the have multiple send and receive operations outstanding for a request, and sends a reply. This continues until the server single TCP stream, as well as across multiple TCP streams. replies to the final client request and then closes the connec- This can lead to higher network bandwidth and less latency tion. Several of these steps can block on interaction with for a single application. a remote host, the network, some other subsystem (e.g., a Since an application executes in user space and the PPE database), and potentially a disk. Consequently, for high executes as a kernel thread, they do not share virtual ad- performance the server must handle up to several thousand dresses. When an application references a buffer, the ap- simultaneous connections [10] and quickly multiplex connec- plication’s virtual address needs to be mapped to a virtual tions that are ready to be serviced. One approach is to as- address accessible by the PPE. To perform this mapping we sign each connection to a separate thread of execution which require an application to register memory prior to referenc- can block [1, 39]. However, the cost of frequently switching ing it in send and receive operations. Registering memory execution contexts can limit the application’s performance. returns a handle to be included in calls to DUSI I/O func- An alternative approach which avoids this problem is to tions. When memory is registered ETA makes certain that use a Single Process Event Driven (SPED) application archi- all user memory, including anonymous memory, is backed by tecture (terminology from [39]). A SPED architecture uses a physical pages. ETA also takes advantage of registration to single process (per CPU) running an infinite event process- pin the pages in memory, preparing the pages to be accessed ing loop. In each loop iteration an event notification mech- by the NIC. anism identifies a connection that is ready for additional Prior research [22, 31, 16] has shown the benefits of copy processing, and then the processing for this connection is avoidance in network performance. When sending data, performed in a non-blocking fashion [13, 5]. With this ap- ETA minimizes copies by writing directly from the user proach, a process can service a large number of connections buffer to the NIC. This is easily and efficiently done be- concurrently without being blocked on an I/O operation and cause the application buffer is already mapped to a kernel without the overheads of multithreading [52]. However, it virtual address and pinned in memory. Since retransmis- may still be necessary to use multiple processes per proces- Accepting prepost read 6.3 The userver with AIO: Startup Accepting prepost accept accept_compl At startup the userver calls DUSI to create the user adap- accept read_compl Connected tation layer (UAL), EvQs, and multiple child sockets, and Reading read
As described earlier, the userver also posts a receive opera- ® Intel PRO/1000 gigabit network interfaces (NICs). Eight tion to the child DTI. As a result, the sum of the number of HP Integrity rx2600 machines act as clients. A switch in- active connections plus the number of new connections that terconnects all the machines, and the network is configured can be accepted remains constant. This is similar to a listen to support two clients on each server NIC’s subnet. Each queue in the case of standard BSD sockets. of these machines is also connected to a control machine on 6.5 The userver with AIO: Summary a distinct control network, which is used to control experi- ments and collect results. In adapting the userver to use asynchronous I/O, we iden- Our ETA+AIO experiments dedicate one CPU to the tified several important considerations. One is that some PPE and the second (host) CPU runs one instance of the events can implicitly indicate the completion of other events. userver. For our experiments with the standard Linux stack For example, the successful reception of data could be an (baseline), we use best-practice configurations to maximize indication that an accept or prior send has also completed. baseline system performance. Specifically, the baseline con- With this in mind, different event types can be assigned figurations bind a userver process and the interrupts from to separate queues, thus permitting the userver to make the interfaces it listens on to the same CPU [8]. For our two- application-driven decisions about which events to priori- CPU server, each CPU runs a single userver process which tize. Another important factor is having the AIO interface listens on the IP addresses of two of the four network inter- allow reads to be posted on future connections before they faces. We use epoll in the baseline, which we found to be are accepted. This can be used to avoid race conditions more efficient than poll or select. We configure each NIC where the application is notified of a connection being ac- to use checksum offloading, and for baseline configurations cepted but is unable to post a read request prior to the data we also enable the dynamic interrupt throttling capability arriving. This is important because if a read is posted the of each NIC to minimize interrupt overhead. We do not use PPE can immediately deliver a notification to the applica- TCP segmentation offload (TSO) because it is not supported tion, otherwise it must delay delivering the event until the by ETA+AIO’s 2.4.16-based networking stack. We would read is eventually posted. Finally, an asynchronous I/O in- expect TSO to provide comparable benefits for ETA+AIO terface can be very efficient. However, if there are no events and the baseline. to be processed the application must wait for events, and kernel assistance is required to block the application and 7.2 Overall Network Processing Performance later unblock it when an event does arrive. As we discuss in To obtain a high-level characterization of the performance Section 7.3 the overhead of using signals as an event notifi- benefits of ETA+AIO, we evaluate the ETA+AIO prototype cation system can be costly relative to other costs associated and baseline configurations in terms of two key performance packet. To avoid this artifact in our analysis, we embed- attributes: network processing efficiency, which we define ded the HTTP header into the URI files. This has a very as the fraction of CPU cycles that are available for addi- small positive effect on the baseline experiments in that the tional application processing, and peak throughput. For any header is sent via sendfile rather than from a user buffer. fixed level of delivered throughput, configurations with lower higher network processing efficiency than the baseline con- ETA vs Baseline Efficiency figurations. In addition, for future systems with a larger ETA Baseline w/ sendfile Baseline w/o sendfile number of processor cores, a single PPE will comprise a lower percentage of total CPU cycles than 50%, likely nar- 100 rowing the region of light load levels where ETA+AIO has 90 80 worse network processing efficiency. 70 Compared to the baseline without sendfile, ETA+AIO 60 achieves higher network processing efficiency over a wide 50 range of throughput (higher than 1300 Mbps) and also 40 supports a higher peak throughput (2266 Mbps versus 30 20 1917 Mbps). These improvements can be largely attributed
CPU Utilization (2 CPUs) Utilization CPU 10 to the elimination of transmit-side copies in ETA+AIO. This 0 result suggests that applications that are not able to use 0 500 1000 1500 2000 2500 3000 copy-avoidance primitives such as sendfile can see signifi- Throughput (Mbps) cant performance benefits with ETA+AIO. ETA+AIO also achieves higher network processing effi- ciency than the baseline with sendfile, but over a nar- rower range of high throughput starting at 2000 Mbps. Figure 4: Processing Efficiency and Capacity For example, at 2266 Mbps throughput, ETA+AIO has 9% more cycles available for application processing than the baseline with sendfile (62% versus 71% utilization at CPU utilization have higher network processing efficiency, the same throughput). The efficiency improvement shows since they leave a larger fraction of CPU cycles available for that additional architectural aspects of ETA+AIO besides additional application processing. transmit copy elimination benefit network processing. De- Figure 4 plots the CPU utilization (aggregate of the spite these improvements, the ETA+AIO prototype achieves vmstat two CPUs, measured with ) required to achieve lower peak throughput than the baseline with sendfile each level of throughput for ETA+AIO and two baseline (2266 Mbps versus 2832 Mbps). Although the ETA+AIO configurations, using the userver and the SPECweb99-like system has a substantial fraction of idle CPU cycles at its workload. For each configuration, the rightmost data point peak throughput, the PPE CPU is saturated, preventing ad- corresponds to the peak throughput achieved with that ditional network processing. However, these cycles can be configuration. This value represents the actual system utilized for other application processing, potentially allowing capacity, free of artifacts like AIO error cases, which never ETA+AIO to support higher throughputs for an application occur in these experiments. We compare ETA+AIO against with a larger component of application computation (e.g., a baseline configurations that use the Linux 2.4.18 kernel webserver generating dynamic content). with a processor affinity patch, since the 2.4.18 kernel is ‡ To study this effect, we next evaluate performance on a the basis for the ETA+AIO prototype . In one baseline workload that includes the encryption of a subset of the files. configuration the userver application uses the write system We extend the userver to encrypt a configurable percentage call to transmit data as is commonly the case when sending of the files that are at most 7500 bytes in size. In these write dynamic content instead of static content. The experiments, to maximize efficiency the baseline system uses system call incurs the overhead of a memory-to-memory sendfile to transmit all data, including the dynamically copy from the user data buffer to kernel socket buffers. In encrypted files. the other baseline configuration, the userver application Figure 5 shows the peak throughput and CPU utilization sendfile uses the “zero-copy” system call to transmit data for various levels of encryption. Since our ETA+AIO proto- without memory-to-memory copies. type statically allocates the application and PPE CPUs, it Figure 4 shows that, as expected, network processing ef- does not compare favorably to the baseline when the CPU ficiency and peak throughput in the baseline substantially demand is biased toward either networking or the userver improve with the use of sendfile. The baseline without application. However, the ETA+AIO prototype achieves sendfile achieves a peak throughput of 1916 Mbps, while higher throughput than the baseline for encryption percent- the baseline with sendfile achieves 2832 Mbps. These re- ages in the range between 25% and 55%. Furthermore, sults reflect the performance capabilities of the kernel and within this range the ETA+AIO prototype often has lower network stack implementations since the peak throughput CPU utilization than the baseline. is limited by the saturated CPU rather than bottlenecks in the memory or I/O subsystems. The results for ETA+AIO in Figure 4 show that its aggre- 7.3 Detailed Performance Analysis gate CPU utilization is always at least 50%, because in our Section 7.2 identified workload regions in which the server one of the two CPUs runs the continuously polling ETA+AIO prototype has a modest advantage over the best PPE. Thus, at low network throughputs when the PPE baseline configuration in throughput and efficiency. We next CPU is not well-utilized, the network processing efficiency of present a detailed analysis to identify and quantify the rea- the ETA+AIO system is considerably worse than the base- sons for the observed efficiency advantages. line configurations. In contrast, at high network loads the Whereas our prototype assigns a single CPU for use by PPE CPU is effectively utilized enabling ETA+AIO to have the networking stack (PPE), with the 2-CPU baseline sys- tem there may be an instance of TCP/IP executing on each ‡We compared a 2.6 kernel’s networking to the 2.4.18 kernel processor. Due to cache conflicts and semaphore contention, and saw only a small performance increase. TCP/IP tends to scale less than linearly on baseline systems Though for this workload the ETA+AIO prototype is no ETA vs Baseline Throughput w/ Encryption more efficient than the 2-CPU baseline after discounting the ETA CPU Utilization Baseline CPU Utilization multiprocessing overhead, we wish to determine if the two ETA Throughput Baseline Throughput architectures are exhibiting equivalent behavior. For exam- 100 3000.0 ple, features of the ETA+AIO architecture may be providing 90 80 2500.0 efficiency benefits that are offset elsewhere. To understand 70 2000.0 how CPU cycles are distributed in the ETA+AIO architec- 60 ture versus the baseline architecture, we collect data from 50 1500.0 40 the hardware performance counters using oprofile [2]. We 30 1000.0 choose a target rate of 18800 requests per second, which re- CPU UtilizationCPU
20 500.0 (Mbps)Throughput sults in a throughput of 2218 Mbps. This is slightly less than 10 0 0.0 the peak ETA+AIO throughput because peak throughput
0 5 is slightly degraded when oprofile sampling is enabled. We 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 group the oprofile results into the following bins: Percent of files <= 7500 bytes encrypted Userver Includes the userver code plus time spent in li- braries called by the userver, including libc, the DUSI Figure 5: Peak Throughput and CPU Utilization library, and the AIO mapping layer. with an Application Workload TCP/IP Contains functions we are able to attribute to TCP/IP processing. In order to ensure that the
Efficiency Graph (No Encryption) ETA+AIO and baseline TCP/IP bins include only similar functionality, the baseline TCP/IP bin ex- ETA 2-CPU baseline w/ sendfile 2-CPU baseline w/o sendfile 1 CPU baseline w/ sendfile (normalized) cludes socket system calls.
100 Ethernet Contains the NIC device driver and general de- 90 vice processing that we directly attribute to the NICs 80 70 (or is dominated by the NICs such that other devices 60 are insignificant). For the baseline, this includes the 50 cost of NIC interrupts; for ETA+AIO, it includes the 40 cost of NIC polling. CPU Utilization 30 20 Kernel other A catchall bin for kernel processing that 10 does not fall into the other bins. This includes func- 0 0 500 1000 1500 2000 2500 3000 3500 4000 tions that cannot be attributed to the other bins (e.g., Throughput (Mbps) memory allocation, where we cannot reliably deter- mine which calls are a result of TCP/IP, the Ethernet driver or elsewhere). Socket and file-related functions Figure 6: Processing Efficiency with Normalized 1- are included in this bin. CPU Data PPE other Consists of oprofile samples consumed by the PPE that are not directly attributable to TCP/IP or Ethernet processing. This bin includes the polling of with multiple CPUs. Therefore, it is important to determine the application queues. what portion of the ETA+AIO prototype’s benefit is a result of running only a single instance of the networking stack. We Table 1 shows the measured distribution of CPU cycles for conduct experiments to understand this effect, and so that the workload without encryption. These results show that we may factor it out when comparing the baseline to the the ETA+AIO system has a nearly identical percentage of ETA+AIO architecture. idle cycles compared to the idealized and normalized 1-CPU To evaluate the benefits of performing packet processing system (39.24% versus 40.08%), and a significantly greater on only one CPU, we measure a baseline configuration exe- percentage of idle cycles than the actual 2-CPU baseline cuting with only one CPU enabled. For this configuration, system (29.30%). The ETA+AIO idle cycles are all on the we use only two NICs rather than four and execute at half host CPU since the PPE CPU is continuously polling. In the HTTP request rate of the 2-CPU systems. We normal- addition to the polling of NICs attributed in the Ethernet ize the 1-CPU results to the ETA+AIO and 2-CPU results bin, the PPE is also continuously polling the application’s by doubling the 1-CPU system’s observed throughput. This DbQ and the Administrative Queue (Figure 2). The cost normalized 1-CPU baseline provides a best-case representa- of the application polling manifests itself in the PPE other tion of an idealized 2-CPU baseline which would be free of bin. Our examination of the oprofile details indicates that the effects of multi-processor networking stack contention. approximately half of the PPE other cycles in Table 1 are In Figure 6 we compare the normalized 1-CPU baseline consumed by unproductive polling. (utilizing sendfile) against the real 2-CPU baselines and The results for the TCP/IP bin in Table 1 show that the ETA+AIO prototype. At the peak throughput for the ETA+AIO prototype executes TCP/IP more efficiently ETA+AIO, CPU utilization roughly matches the 1-CPU than the 2-CPU baseline with sendfile. However, the baseline. Hence it appears that much of the benefit of our ETA+AIO prototype and the normalized 1-CPU system prototype versus the 2-CPU baseline does come from avoid- have very similar TCP/IP performance. As discussed ear- ing multiprocessing overheads for packet processing. lier, the ETA+AIO prototype’s TCP/IP stack benefits from Table 1: ETA+AIO vs Baseline CPU Utilization Table 2: ETA+AIO vs Baseline Cache Misses (No Baseline Baseline Encryption). Equal normalized throughputs Bin ETA+AIO 2-CPUs 1-CPU Idle 39.24% 29.30% 40.08% Baseline Baseline Userver 6.89% 5.48% 5.32% Cache ETA+AIO 2-CPUs 1-CPU TCP/IP 25.02% 29.51% 25.54% L3 Misses 1.43 1.34 1.00 Ethernet 15.01% 19.19% 16.82% L2 Misses 1.01 1.16 1.00 Kernel other 8.31% 16.40% 12.09% PPE other 5.43%
Table 3: ETA+AIO vs Baseline Cache Misses (With Encryption). Equal normalized throughputs executing on just a single processor. It is not surprising that the ETA+AIO TCP/IP bin is not noticeably more efficient Baseline Baseline than that of the 1-CPU system when there is no encryption Cache ETA+AIO 2-CPUs 1-CPU workload. Since we have not changed the TCP/IP stack, the L3 Misses 1.00 1.38 1.00 only expected improvement would be due to better cache be- L2 Misses 0.71 1.13 1.00 havior. On our measurements of encryption workloads we do observe small but consistent improvements in ETA+AIO TCP/IP efficiency over a 1-CPU system. For example, when we sampled a 15400 request per second workload encrypting NIC interrupt moderation timers. 40% of files not greater than 7500 bytes, the ETA+AIO sys- Since ETA+AIO partitions the networking stack from the tem spent 20.05% of its time in TCP/IP, while the 1-CPU application with a goal of reducing resource contention, we system consumed 21.63% of the CPU cycles. use oprofile to evaluate the impact of partitioning on cache Table 1 also shows that the baseline spends more time behavior. We note that the unified caches of the Xeon ç in the kernel (16.40% for the 2-CPU system and 12.09% processor preclude measurement of separate cache behav- for the 1-CPU system) than the ETA+AIO system (8.31%). ior for instructions and data. Table 2 shows the relative An analysis of the detailed oprofile data shows that most of number of all Level-3 (L3) and Level-2 (L2) cache misses the baseline’s kernel overhead is attributed to sockets and for ETA+AIO, a 2-CPU baseline system and a normalized epoll. In addition, this analysis shows that signals and syn- (half-rate) 1-CPU baseline system when the userver applica- chronous DUSI events (e.g., creating and destroying DTIs) tion has no additional computation to perform (i.e., execut- are a substantial part of the ETA+AIO architecture’s kernel ing without encryption enabled). The values are reported overhead. Recall that the application uses signals only when relative to the normalized 1-CPU baseline cache miss counts. it must wait for a new event to arrive to empty event queues. For example, in Table 2 the 2-CPU baseline has 34% more This requires the userver to make several signal-related sys- L3 cache misses per CPU than the 1-CPU baseline. Table 3 tem calls. In addition, any DUSI synchronous calls invoke presents the relative L3 and L2 cache misses for a workload an ioctl system call to schedule the ETA Kernel Agent. where the userver does have additional computation to per- When the PPE raises a signal or completes a synchronous form (i.e., encrypting 40% of the files not greater than 7500 event, the Kernel Agent is scheduled via an Interprocessor bytes). Interrupt (IPI). Though the AIO interface provides signifi- Table 2 shows that without additional application compu- cant benefits over sockets and epoll, the gains are partially tation (no encryption) the ETA+AIO system has a higher mitigated by the overhead of signals waiting for events. Our L3 cache miss rate than both baseline configurations. This analysis of the oprofile data shows the combined cost of can be attributed to the cache-to-cache transfers between signal-specific kernel functions, the ETA kernel agent, IPIs the host CPU and the PPE for the DTI interactions. How- and system calls to be 2.70% of the system’s CPU cycles, or ever, Table 3 shows that with an encryption workload the approximately a third of the ETA+AIO kernel overhead. In rate of L3 cache misses between ETA+AIO and the 1-CPU Figure 4 we note that as ETA+AIO begins to reach its peak baseline system is comparable, and much better than the throughput it becomes more efficient. This is because at 2-CPU baseline. An analysis of the oprofile data indicates high loads the userver is more likely to find an event on its that without encryption ETA+AIO incurs approximately queues, and thus less likely to incur the overhead of signals. 1273 L3 cache misses per megabit of data served, while the Table 1 shows that the ETA+AIO Ethernet component 1-CPU baseline incurs roughly 890 L3 misses per megabit. consumes less CPU cycles (15.01%) than both the 2-CPU For the encryption workload, the ETA+AIO L3 cache miss and 1-CPU baseline Ethernet components (19.19% and rate increases slightly to about 1310 L3 misses per megabit, 16.82%, respectively). This is despite the PPE’s continu- while the 1-CPU baseline system’s L3 cache miss rate in- ous polling of NICs, which consumes CPU cycles even when creases over 45% to approximately 1310 misses per megabit. no packets are available. A more detailed analysis of the The additional encryption workload increases the cache con- oprofile data reveals that the ETA+AIO architecture bene- tention between the application and the network stack on fits from not having to incur the overhead of hardware inter- baseline systems. When a file is encrypted, the userver ap- rupts, and from not having to go through the Linux SoftIRQ plication reads the original file and writes encrypted data to path. However, these operations are quite efficient on the an encryption buffer, potentially causing evictions from the baseline system, accounting for only slightly more than 2% L3 cache. For a 1-CPU baseline system with an encryption of the overall system overhead. The low cost of interrupts workload, encrypting the data accounts for almost 17% of on the baseline system is likely due to the effective use of the L3 cache misses. For the ETA+AIO system an evic- tion in the application processor’s L3 cache does not affect An important question to answer is how PPE scaling affects PPE packet processing, and thus processor partitioning re- the performance benefits of processor partitioning. For ex- duces the impact of the additional application computation ample, in our study the bottleneck was the CPU cycles avail- on the L3 cache miss rate. In contrast to the 1-CPU base- able in the PPE (or the host CPU). By adding PPEs, the line, ETA+AIO encryption accounts for roughly only 10% bottleneck resource can shift from CPU cycles to memory of the total L3 cache misses. bandwidth, at which point the cache benefits of partitioning Table 2 shows that ETA+AIO’s L2 cache behavior is simi- will likely become more important than we have observed in lar to the 1-CPU baseline when there is no encryption work- our investigation. With multiple PPEs, additional issues load. However, as we add the encryption application work- arise such as finding the best assignment of responsibility load (Table 3) the ETA+AIO system L2 cache behavior be- for the NICs in a system to the various PPEs. In order comes substantially better than the baseline. We attribute to keep up with the link speed of a single high-speed (e.g., this to the network stack and application partitioning, as 10 GigE) NIC, it may be necessary for multiple PPEs to we expect the ETA+AIO architecture to have better local- share a single NIC, perhaps by spreading TCP connections ity and a smaller per-CPU instruction working set compared for the NIC across the PPEs as proposed by Microsoft’s to the baseline. receive-side scaling (RSS). For implementations that sup- port multiple PPEs, the number of PPEs should be dynam- 7.4 Summary of Results ically varied in proportion to the workload. Using a web server workload with a configurable com- Scheduling issues are also interesting to investigate. AIO putational component (encryption), our performance eval- enables applications to present large numbers of concurrent uation has characterized workload conditions where either operations to the PPE. In our prototype, some scheduling the ETA+AIO prototype or the baseline provides superior parameters in the PPE loop are chosen through trial-and- performance or efficiency. Our detailed performance analy- error, such as the number of entries to dequeue from a NIC sis provides insight into the reasons for this behavior. Our in each loop iteration. Different choices may be optimal for results show that the transmit-side copy avoidance in the different workloads, and a method for dynamically tuning prototype results in significantly better processing efficiency the scheduling of PPE operations may yield higher through- and higher peak throughput than a baseline system that uses put. In addition, application performance may depend on the standard write system call to transmit replies to web the order in which the application processes events. clients. After factoring out the impact of copy avoidance by The benefits of processor partitioning may be greater for using a baseline system that uses the sendfile system call, emerging multi-core processor architectures than in our pro- the prototype retains a (smaller) efficiency advantage over totype, for example due to on-chip mechanisms for fast com- the baseline. This efficiency advantage only partially off- munication between processor cores. In addition, network sets the fact that for packet processing, the baseline system interface logic may become integrated onto the same chip uses two CPUs whereas the prototype uses only one (the as the processor cores, avoiding the costs of traversing off- PPE CPU). Hence, for workloads with lightweight applica- chip I/O links such as PCI. It is important to understand tion processing requirements, the prototype achieves a lower how this integration would affect the performance behavior peak throughput than the sendfile baseline. For workloads of the ETA+AIO and baseline architectures. in which application processing and packet processing bet- ter match the CPU allocation, the prototype can achieve 9. CONCLUSIONS marginally higher peak throughput than the baseline. The high cost of TCP/IP packet processing and the emer- By comparing a one-CPU version of the sendfile baseline gence of high-speed network links such as 10 gigabit Eth- to the prototype, we show that most of the efficiency ben- ernet pose an important challenge for next-generation sys- efits of the prototype come from avoiding the overheads of tems. In this paper we presented the design and evalua- multiprocessing for packet processing (since the prototype tion of a prototype implementation of the ETA+AIO archi- uses only a single PPE CPU). The detailed breakdown of tecture which addresses this problem by dedicating proces- CPU execution time shows that additional efficiency bene- sors to packet processing and by exposing asynchronous I/O fits come from the use of the AIO interface, which has lower (AIO) semantics to applications. We also presented a case overhead than the standard sockets interface. For memory- study showing how the use of asynchronous network socket intensive application workloads, processor partitioning elim- primitives affects the design of a real server application. inates contention between the application and TCP process- Compared to previous work, the evaluation presented ing for a shared processor cache, and hence reduces cache in this paper provides a more accurate and comprehen- misses compared to baseline systems. Finally, the signal sive assessment of the potential benefits of approaches that mechanism used by the application to wait for events when dedicate CPU cores to networking, particularly in light of all the event queues are empty can introduce significant over- recent advances in OS and TCP stack implementations. head and should be replaced by some lighterweight mecha- Prior investigations of ETA and a similar architecture (TCP nism. However, this problem occurs only for intermediate Servers) have the disadvantage that they only compared traffic loads, since at low loads the CPU usage is negligible, their approaches against baseline systems that did not use and at high loads event queues are empty less often. best-practice configurations and did not use OS features that have recently become available to improve performance. 8. ARCHITECTURAL EXTENSIONS In contrast, our evaluation makes full use of current best- Our analysis points to many interesting directions to ex- practice techniques including use of the sendfile system tend the implementation and investigation of the ETA+AIO call, processor affinity for both processes and interrupts, and architecture. To support higher throughputs, the ETA pro- NIC hardware support for interrupt moderation and TCP totype should be extended to scale to multiple PPE CPUs. checksumming. In our experience, use of these features for the baseline system significantly improves performance, as [8] V. Anand and B. Hartner. TCP/IP network stack reported in recent literature (e.g., [19]). Therefore, the re- performance in Linux kernel 2.4 and 2.5. In sults of our study differ substantially from previous results, Proceedings of the Linux Symposium, pages 8–30. showing more nuanced benefits for processor partitioning Ottawa, Ontario, Canada, July 2003. than have prior investigations which have claimed improve- [9] B. S. Ang. An evaluation of an attempt at offloading ments in peak throughput on the order of 30% [42, 44, 41]. TCP/IP processing onto an i960rn-based NIC. Our results (summarized in Section 7.4) show that the Technical Report HPL-2001-8, HP Labs, Palo Alto, ETA+AIO prototype provides marginally greater process- CA, Jan 2001. ing efficiency than standard systems by avoiding multipro- [10] G. Banga, J. Mogul, and P. Druschel. A scalable and cessing overheads for packet processing and by using the explicit event delivery mechanism for UNIX. In lower overhead AIO API instead of sockets. Also, proces- Proceedings of the 1999 USENIX Annual Technical sor partitioning reduces cache misses for memory-intensive Conference. Monterey, CA, June 1999. applications. For workloads in which application processing [11] A. V. Bhatt. Creating a PCI Express interconnect. and packet processing approximately match the CPU allo- URL www.pcisig.com/specifications/pciexpress/ cations, the ETA+AIO prototype effectively utilizes both technical library/pciexpress whitepaper.pdf. the host and PPE CPUs, leading to higher peak throughput [12] N. L. Binkert, L. R. Hsu, A. G. Saidi, R. G. using fewer CPU cycles. Dreslinski, A. L. Schultz, and S. K. Reinhardt. In addition to presenting the performance evaluation, we Performance analysis of system overheads in TCP/IP also described in detail the issues involved in using asyn- workloads. In Proceedings of the 14th International chronous socket I/O to implement an event-driven web Conference on Parallel Architectures and Compilation server application. We described the construction of the Techniques. St. Louis, September 2005. finite-state machine which handles each connection. We de- [13] T. Brecht and M. Ostrowski. Exploring the termined that only a subset of the event types is needed performance of select-based internet servers. Technical to drive the state machine operation, while other event Report HPL-2001-314, HP Labs, November 2001. types can be ignored. We also discussed the challenges of managing memory registration and de-registration, and the [14] T. Brecht, D. Pariag, and L. Gammo. accept()able scheduling opportunities provided by the ability to use mul- strategies for improving web server performance. In tiple event queues. The userver implementation using the Proceedings of the 2004 USENIX Annual Technical AIO API is open source software. Conference. Boston, June 2004. Although our prototype demonstrated only modest per- [15] D. Clark, V. Jacobson, J. Romkey, and H. Salwen. An formance advantages over the well-configured baseline sys- analysis of TCP processing overhead. IEEE tem, our investigation motivates a number of additional Communications Magazine, 27(6):23–29, June 1989. investigations as outlined in Section 8 which may lead to [16] Z. Ditta, G. Parulkar, and J. Cox Jr. The APIC greater performance improvements in the future. These in- approach to high performance network interface vestigations include scaling to multiple PPEs, changing PPE design: Protected and other techniques. In Proceedings and application scheduling policies, and exploiting features of IEEE INFOCOM ’97, volume 2, pages 7–11, April of multi-core processors like fast inter-processor communi- 1997. cation which may improve the benefits of partitioning. [17] D. Dunning, G. Regnier, G. McAlpine, D. Cameron, B. Shubert, F. Berry, A. M. Merritt, E. Gronke, and Acknowledgements C. Dodd. The Virtual Interface Architecture. IEEE Micro, 18(2):66–76, March-April 1998. The authors gratefully acknowledge the contributions of Paul [18] K. Elmeleegy, A. Chanda, A. L. Cox, and
Stillwell, Jr., John Wiegert, Phil Cayton, Jeff Gray, and W. Zwaenepoel. Lazy asynchronous I/O for ® Greg Regnier of Intel Corporation on the design and de- event-driven servers. In Proceedings of the 2004 velopment of the ETA software prototype. In addition, USENIX Annual Technical Conference. Boston, June Tim Brecht gratefully acknowledges the financial support 2004. of Hewlett-Packard, the Ontario Research and Development [19] A. Foong, J. Fung, and D. Newell. An in-depth Challenge Fund, and the National Sciences and Engineer- analysis of the impact of processor affinity on network ing Research Council of Canada. Furthermore, the authors performance. In IEEE International Conference on would like to acknowledge the efforts of the reviewers and Networks, November 2004. our shepherd Alan Cox for their insightful comments that [20] A. Foong, T. Huff, H. Hum, J. Patwardhan, and have improved the clarity of the paper. G. Regnier. TCP performance re-visited. In IEEE International Symposium on Performance of Systems 10. REFERENCES and Software, March 2003. [1] Apache. URL www.apache.org. [21] D. Freimuth, E. Hu, J. LaVoie, R. Mraz, E. Nahum, [2] OProfile. URL oprofile.sourceforge.net/news/. P. Pradhan, and J. Tracey. Server network scalability [3] RDMA Consortium. URL www.rdmaconsortium.org. and TCP offload. In Proceedings of the 2005 USENIX [4] Sockets API Extensions. URL www.opengroup.org. Annual Technical Conference, pages 209–222. [5] Zeus Technology. URL www.zeus.co.uk. Anaheim, April 2005. [6] Design notes on asynchronous I/O (aio) for Linux, [22] A. Gallatin, J. Chase, and K. Yocum. Trapeze/IP: 2002. URL lse.sourceforge.net/io/aionotes.txt. TCP/IP at near-gigabit speeds. In Proceedings of 1999 [7] The Open Group Base Specifications Issue 6 IEEE USENIX Technical Conference (Freenix Track), pages Std 1003.1, 2003 Edition. 109–120, June 1999. [23] J. M. Hart. Win32 System Programming. Addison [40] M. Rangarajan, K. Banerjee, J. Yeo, and L. Iftode. Wesley, 2nd edition, 2001. MemNet: Efficient offloading of TCP/IP processing [24] HP Labs. The userver home page, 2005. URL using memory-mapped communication. Technical www.hpl.hp.com/research/linux/userver. Report DCS-TR-485, Rutgers University Technical [25] R. Huggahalli, R. Iyer, and S. Tetrick. Direct cache Report, 2002. access for high bandwidth network I/O. In Proceedings [41] M. Rangarajan, A. Bohra, K. Banerjee, E. Carrera, of the 32nd International Conference on Computer R. Bianchini, L. Iftode, and W. Zwaenepoel. TCP Architecture (ISCA’05). Madison, WI, June 2005. Servers: Offloading TCP processing in Internet TM [26] InfiniBandSM Trade Association. InfiniBand servers. Technical Report DCS-TR-481, Rutgers Architecture Specification Volume 1, Release 1.0. University, Mar 2002.
October 2000. URL www.infinibandta.org. [42] G. Regnier, D. Minturn, G. McAlpine, V. Saletore, ® [27] Intel ® Corporation. PCI/PCI-X Family of Gigabit and A. Foong. ETA: Experience with an Intel Ethernet Controllers Software Developer’s Manual, Xeonç processor as a packet processing engine. In Hot Revision 2.5. July 2005. Interconnects, August 2003. [28] V. Jacobson and B. Felderman. A modest proposal to [43] G. J. Regnier, S. Makineni, R. Illikkal, R. R. Iyer, help speed up and scale up the linux networking stack. D. B. Minturn, R. Huggahalli, D. Newell, L. S. Cline, In linux.conf.au, January 2006. and A. Foong. TCP onloading for data center servers. [29] J. Kay and J. Pasquale. The importance of non-data IEEE Computer, 37(11):48–58, 2004. touching processing overheads in TCP/IP. In [44] V. A. Saletore, P. M. Stillwell, J. A. Wiegert,
SIGCOMM, pages 259–268, 1993. P. Cayton, J. Gray, and G. J. Regnier. Efficient direct
® ç [30] J. Kay and J. Pasquale. Profiling and reducing user level sockets for an Intel Xeon processor based processing overheads in TCP/IP. IEEE/ACM TCP on-load engine. In The Workshop on Transations on Networking, 4(6):817–828, 1996. Communication Architecture for Clusters. Denver, CO, April 2005. [31] Y. Khalidi and M. Thadani. An efficient zero-copy I/O framework for UNIX. Technical report, SMLI [45] J. H. Salim, R. Olsson, and A. Kuznetsov. Beyond TR95-39, Sun Microsystems Lab, May 1995. Softnet. In 5th Annual Linux Showcase and Conference, pages 165–172, November 2001. [32] D. Libenzi. Improving (network) I/O performance. URL http://www.xmailserver.org/linux-patches/ [46] P. Sarkar, S. Uttamchandani, and K. Voruganti. nio-improve.html. Storage over IP: when does hardware support help? In 2nd USENIX Conference on File and Storage [33] J. C. Mogul. TCP offload is a dumb idea whose time Technologies (FAST), Mar 2003. has come. In 9th Workshop on Hot Topics in Operating Systems (HotOS IX). USENIX, May 2003. [47] P. Shivam and J. S. Chase. On the elusive benefits of protocol offload. In ACM SigComm Workshop on [34] J. C. Mogul and K. K. Ramakrishnan. Eliminating Network-IO Convergence (NICELI). Germany, August receive livelock in an interrupt-driven kernel. ACM 2003. Transactions on Computer Systems, 15(3):217–252, 1997. [48] Standard Performance Evaluation Corporation. SPECweb99 Benchmark, 1999. URL [35] D. Mosberger and T. Jin. httperf: A tool for www.spec.org/osg/web99. measuring web server performance. In First Workshop on Internet Server Performance, pages 59—67. [49] W. Stevens. Unix Network Programming, Volume 1. Madison, WI, June 1998. Addison Wesley, third edition, 2003. [36] S. Muir and J. Smith. AsyMOS – an asymmetric [50] Y. Turner, T. Brecht, G. Regnier, V. Saletore, G. J. multiprocessor operating system. In IEEE Conf on Janakiraman, and B. Lynn. Scalable networking for Open Architectures and Network Programming next-generation computing platforms. In Third (OPENARCH), April 1998. Annual Workshop on System Area Networks (SAN-3). Madrid, Spain, February 2004. [37] S. Muir and J. Smith. Functional divisions in the Piglet multiprocessor operating system. In ACM [51] M. Welsh, D. Culler, and E. Brewer. SEDA: an SIGOPS European Workshop, September 1998. architecture for well-conditioned, scalable Internet services. In 18th Symp. on Operating System [38] S. Nagar, P. Larson, H. Linder, and D. Stevens. epoll Principles (SOSP-18), Oct 2001. scalability web page. URL http://lse.sourceforge.net/epoll/index.html. [52] N. Zeldovich, A. Yip, F. Dabek, R. T. Morris, D. Mazieres, and F. Kaashoek. Multiprocessor support [39] V. S. Pai, P. Druschel, and W. Zwaenepoel. Flash: An for event-driven programs. In Proceedings of the efficient and portable Web server. In Proceedings of USENIX 2003 Annual Technical Conference, June the USENIX 1999 Annual Technical Conference, 1999. 2003.