Adam Belay, George Prekas, Ana Klimovic, Samuel Grossman, Cristos Kozyrakis, Edouard Bugnion 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14)
개요
IX는 Data plane과 Control plane이 혼합되어 있는 리눅스 커널의 Network stack을 분리하여서, Hardware-based isolation기법의 도움을 통해서 Data plane은 유저 프로그램에, 그리고 Control plane은 커널에 두도록 하여서, Batching, Run-to-complete과 같은 새로운 Event-based networking이 가능하도록 하여, Network stack의 성능향상을 도모하였다.
Motivation
네트워킹은 점점더 빨라지고 리눅스 Network stack은 점점 바틀넥이 되고 있다. 네트워킹에서 Performance그리고 Protection이 중요한 과제이다. 이 두조건은 한쪽을 취하면 다른쪽을 포기해야 하는 관계로 알려져 있었다. 특히 Batching과 같은 방식을 사용하면 Throughput올라가지만, Latency는 떨어진다고 알려져 있다.
Importance
리눅스 커널을 Generality를 위해서 Performance을 어느정도 타협하였기 떄문에, 이를 극복하기 위한 여러 방법들이 있었다. Kernel-bypassing과 같은 경우는 성능을 보장하지만, Protection과 Sharing을 포기해야 하였다. RDMA Offloading과 같은 방식은 특수한 하드웨어를 사용해야 하였다.
Main Idea
IX는 Control plane과 Data plane을 구분하였다. 또한 Data plane에서 zero-copy와 Context change switch의 오버헤드를 줄이는 것을 보장하기 위해서, Dune을 이용하여서 Application의 Dataplane을 커널에서 직접 돌렸다. 이를 통해서 Dataplane은 Network stack을 Kernel의 Application specific data-plane에서 배칭과 Run-to-complete을 통해서 동작하게 하였다. 이를 통해서 IX는 Throughput, Latency, Protection를 달성하였다.
Design
- Data and Control plane
- IX는 Control function (configuration, provisioning, scheduling, monitoring)기능을 Data plane (Network stack, Application logic)으로부터 분리하였다. 이를 통해서 Specialization된 Network stack을 Application이 사용할 수 있도록 하였다.
- Run-to-completion
- 기존의 리눅스 커널은 패킷 처리와, Application처리가 분리되어 있다. 이에 따라서 Scheduling cost, dupulicated copy문제가 발생하였다. IX는 Packet처리와 Application로직이 한번에 일어나서, Cache locality를 살리고 zero-copy로 패킷을 처리할 수 있도록 하였다. 이를 통해서 Latency와 Throughput모두 올릴 수 있었다.
- Batching
- 기존의 리눅스 커널은 각 데이터 하나마다, Network stack, system call layer을 거쳐서 처리되어야 하였다. 그러나 IX는 Adaptive batching을 적용하여서, 여러개의 Data와 System call을 배칭을 통해서 처리하도록 하였다. 이를 통해서 Throughput과 Latency를 모두 올릴 수 있었다. 배칭은 system call overhead를 줄이고, Cache locality를 올리며, Prefetching 효과와 Branch prediction에 긍정적인 영향을 주기 때문에, 성능에 긍정적인 영향을 주었다.
- Near-data processing
- Run-to-completion그리고 Adaptive batching은 NIC이후에 Linux network stack을 타지 않고 처리된다. 따라서 불필요한 스택을 줄이고 Near-data processing을 가능하게 하여서, 성능 향상을 도모할 수 있었다. 또한 Near-data processing을 통해서 Congestion windows와 같이 성능 향상에 직접 영향을 주는 Feature에 대한 fine-grained control이 가능하게 되었다. (예를 들어서 Application성능이 줄면 바로 Congestion window를 줄이는 방식)
- Zero-copy API & Synchronization-free
- IX는 POSIX API를 직접 사용하지 않고, zero-copy에 특화된 API를 제공하였다. 또한 각 코어가 POSIX의 Shared 소켓 모델이 아닌, Dedicated된 패킷을 처리하기 때문에, Synchornization를 Lock으로 걸 필요가 없었다. 이러한 점때문에 IX는 Multi-core환경에서 빠른 성능을 보일 수 있었다.
- Hardware-based virtualization
- 하드웨어 기반 가상화 기법인 Dune을 사용하여서, Data-plane이 안전하게 Kernel에 위치하면서 동시에 User Application이 작성할 수 있도록 하였다. 이는 Data-plane이 Page table, Exception, Pass-through access to NIC과 같은 기능을 사용할 수 있도록 하였다.
- IX Dataplane Design
- IX는 Huge page를 사용하였으며, Data-plane은 Kernel의 Address space를 공유하였다. Application은 Batched된 Payload를 받아서 System call을 Batching으로 내린다. Payload들은 공유된 buffer(mbuf)를 통해서 zero-copy로 소비된다. 이를 위해서 User-level event handler (Elastic thread라고 명명됨)은 Dataplane와 Shared memory를 유지하고 있다. 이러한 작업을 간편하게 처리하기 위해서 libix라는 libevent와 비슷한 Asynchorouns Socket API를 제공하였다.
Conclusion
IX는 Data-plane과 Control-plane을 나누어서 네트워크 스택을 최대한 Near-data processing으로 처리하고자 하는 논문이다. Batching에 관하여, FlexSC와 같은 시스템 콜 배칭이 아니라, 이런식으로 배칭을 처리하여야 하는 것이 진정한 배칭의 효과라는 생각이 들었다. 또한 Near data processing이라는 관점에서, Dune을 사용해서 Application Logic을 이런식으로 처리하는 것의 이점을 알 수도 있었다. 그러나 Sharing/Protection측면에서 이러한 디자인은 Linux kernel보다는 떨어질 것으로 생각한다. 이는 IX의 디자인이 NIC에서 처리한 데이터를 직접 가져온다는 점에 있다. 커널 API에 만약 잘못된 인자를 주면 Attack이 되지 않을까? Time-out interrupt을 사용해서 DOS공격을 막는 것은 조금 Naiive한 방식이라고 생각한다. 만약 10ms보다 더 오래 걸리는 작업을 처리해야 한다면 어떻게 대처할 것인가? 또한 Evaluation이 Optimization인지 아니면 IX의 Design인지에 대해서 약간의 의문이 들 수 도 있다는 생각이 든다. 예를 들어서 Huge page사용은 Cache locality에 큰 영향을 미치는데, Cache locality의 이점이 IX의 디자인에서 온 것인지, 아니면 Linux kernel로 Huge page를 사용하면 비슷한 Cache locality의 이점을 얻을 수 있느지가 의문이다. 그러나 IX의 핵심 아이디어인 Hardware-virtualiation을 통한 Run-to-complete그리고 Data/Control plane분리에 대한 중요성을 보여준 IX시스템의 디자인은 다른 많은 Network optimization 그리고 Kernel design에도 적용시킬 수 있다는 점에서 큰 의의가 있다고 생각한다.