The IX Operating System

Abstract

The conventional wisdom is that aggressive networking requirements, such as high packet rates for small messages and μs-scale tail latency, are best addressed outside the kernel, in a user-level networking stack. We present IX, a dataplane operating system that provides high I/O performance and high resource efficiency while maintaining the protection and isolation benefits of existing kernels.IX uses hardware virtualization to separate management and scheduling functions of the kernel (control plane) from network processing (dataplane). The dataplane architecture builds upon a native, zero-copy API and optimizes for both bandwidth and latency by dedicating hardware threads and networking queues to dataplane instances, processing bounded batches of packets to completion, and eliminating coherence traffic and multicore synchronization. The control plane dynamically adjusts core allocations and voltage/frequency settings to meet service-level objectives.We demonstrate that IX outperforms Linux and a user-space network stack significantly in both throughput and end-to-end latency. Moreover, IX improves the throughput of a widely deployed, key-value store by up to 6.4× and reduces tail latency by more than 2×. With three varying load patterns, the control plane saves 46%-54% of processor energy, and it allows background jobs to run at 35%-47% of their standalone throughput.

Rss++

“…Shinjuku [20] uses RSS to split input load among multiple software-based dispatching cores, which in turn queue and schedule requests to worker cores. Shinjuku improves upon ZygOS for heavy-tailed and multi-modal load distributions, while achieves similar performance with ZygOS and IX [5] for light-tailed workloads. In contrast to ZygOS and Shinjuku, RSS++ allows more efficient connection "stealing" between cores using a hardware-level method (i.e., tweaking the NIC indirection table) available in commodity NICs.…”

Flow control for Latency-Critical RPCs

“…Since we specifically target latency-critical RPC services, we didn't expose a POSIX-like API for our proof of concept TCP stack. Instead, we implemented an event-based API similar to IX [8]. In this API, the application has direct access to the packets received.…”

“…Every thread runs a run-to-completion loop. This is a popular design adopted by latency critical applications, such as NGINX [34] and memcached [30], and operating systems, such as IX [8]. In this design, every thread maintains its own moving averages for service time and inter-arrival distribution that correspond to the connections it is responsible for, and implements flow control based on the load it individually receives.…”

“…Several kernel-bypass systems implement TCP/IP stacks [8,16,17,22,28,29,[35][36][37]39], and remain fully compatible with the exact TCP semantics. Similarly to TCP, protocols such as QUIC [26] and HTTP2 [9], also, implement flow control mechanisms based on buffer occupancy, and remain agnostic to latency SLOs.…”

“…Thus, it assumes certain asynchrony between network and application processing. This assumption is invalid for kernel-bypass implementations with a symmetric, run-to-completion design inspired by middlebox dataplanes [8,37]. Because of the tight coupling of network and application processing, there are no buffered data between the two stages.…”