本文设计实现了一个操作系统IX。它的设计动机来源于云计算时代数据中心应用对于软件架构的新的需求，即高吞吐，低延迟，同时资源高效利用和系统的保护机制也很重要。随着硬件技术的发展，硬件的性能不断提升，传统的软件架构成了当前的性能瓶颈。作者们设计IX的目标就是为了缩小软件性能和硬件性能间的鸿沟。
-
为啥传统软件架构遭遇性能瓶颈？优化目标不一样，应用场合不一样。传统操作系统主要为单CPU多任务时分复用的调度和资源管理做优化。数据中心应用对延迟敏感，且吞吐量大，调度开销、排队开销、缓存等待、同步开销等问题会显著影响任务性能，降低吞吐量。
-
作者关心的任务主要是短小的，network io-bound的任务，因为IX主要针对的是网络IO进行优化。数据中心中其他类型的任务，比如计算密集型，或者长时间运行的离线任务，不是作者的重点优化目标。
对于性能瓶颈传统的解决思路主要有绕过内核、优化网络协议、优化网络硬件等手段，作者在文中比较了各个方法的优劣。
作者针对网络IO做性能优化的一个主要思想是将控制层和数据层隔离，也就是将内核中处理网络栈和应用逻辑的部分，从内核其他功能部分抽离开，形成一个独立的部分，并用独立的CPU核去处理。这个思路和Exokernel有一定相似性，用一个外核针对特定的应用（网络部分）做优化，减小内核其他功能的开销对任务性能带来的负面影响。利用硬件支持的虚拟化技术，每个数据层有独立的地址空间（页表），和IO空间（对网卡进行直接访问）。
数据层内IX和应用分开，通过(non-root)ring0和ring3的特权级差别来实现保护隔离机制（安全）。IX就是一个guest OS，用户态中libIX对IX的一些接口做了封装。
- pass-through access是什么？绕过内核直接访问网卡？一个物理网卡有几个队列？不同数据层是共享同一个物理网卡还是多个物理网卡？
另一个重要思想是run to completion和adaptive batching。批量处理的思想非常朴素，但静态设置的batch size会导致延迟的增长（先来的等后到的）。所以作者采用了动态的batch处理。就好比我们在五道口过马路，凑足了一大波人就一起过马路，没凑足那么多人，绿灯来了也走，降低延迟。 batch size不能太大（缓存友好，且避免队列饥饿）。
run to completion这里我不是很理解。论文中说用户态（应用处理）和内核态交替进行，直到一个packet包处理结束。我理解的是这样的好处一个是减小一些livelock带来的中断的开销，另一个是由于对同一个包的反复访问，数据局部性和代码局部性都较好。但是反面案例是啥？就是这种方式相对应的传统方式具体是啥？这个不太了解细节。
Zero-copy API这块大致应该是减小网络数据在用户空间、内核空间来回拷贝的次数，从而减小延迟（通过对应用只读的共享的message buffer pool实现？）。Zero-copy这块我比较感兴趣，如果老师上课讲这篇论文的话希望请老师介绍下更具体的细节。
flow consistent, 无同步的处理，这一块我理解是讲网络流稳定地分发到不同的硬件队列（一个网卡多个队列？）去处理，每个队列由一个超线程接管。这样线程间不需要同步，减小了开销。网络流到队列的映射关系由控制层负责。
作者还利用了commutative的思想设计系统调用的API，增强了可扩展性。
实验测试部分，作者利用各种benchmark进行了各种测试，主要结论是延迟低，吞吐高，可扩展性好。实际任务测试主要采用了memcached的benchmark，测了延迟和吞吐的关系（在保证延迟满足SLA的条件下，吞吐可以升高到多少）。
作者总结道，IX速度快的原因是数据层的紧耦合，优化应用的调度时机，减小传输开销；减少中间buffer，zero-copy技术，针对多核的可扩展性进行仔细优化。