中文翻译-网络子系统设计

网络子系统设计单纯使用技术来避免工作站上 CPU 和存储器的瓶颈是不够的，必须要把技术集成起来。Peter Druschel,Mark B.Abbott,Machael A.Pagels, Larry L.Peterson新兴的网络技术期望给终端工作站提供接近 1Gbps 的传输带宽，这样的带宽足以带动一类新的应用火热起来。然而，这些得益于高速网络的应用受到一些因素的制约，其中的一个重要因素就是运行在工作站上的操作系统。操作系统必须将良好的网络吞吐率转换为良好的应用程序间吞吐率。Arizona 大学的网络系统研究小组（Network Systems Research Group,以下简称 NSRG）正在研究操作系统支持高速网络的相关问题。这些实验性的工作是在 Mach OS 操作系统的 x 核心1环境下完成的。研制的系统运行在DecStation5000/200 以及 HP 9000/720 工作站上，这些工作站连接着 ATM 网络和 FDDI 网络。大体来讲，Mach 系统提供了一个基于微内核的操作系统框架，而 x 内核相当于其中的网络子系统。我们先在逻辑上将所有的网络协议集中于单个 x 内核协议树中，然后在物理上将这个图结构分布在整个系统中，包括操作系统和应用程序保护域（application protection domain） 。例如，图 1 描述了一个协议树，它连接了一个应用程序、一台专用网络服务器，以及内核。一个特定的协议属于哪个保护域要等到配置时（不是操作系统设计时间）才能决定，从而也能够根据系统配置员对于性能和信任处理的意愿程度。要优化这种结构的性能，就必须解决工作站的存储器结构限制。问题在于工作站存储器性能的提升跟不上处理其性能和网络带宽提升的步伐。例如，Hennessy 和 Patterson 报告指出，自从 1985 年以来，处理器的性能一直以每年50%-100%的速率提升，而存储器的性能提升速率只有 7%。而且，我们希望这种趋势能够持续下去，因为处于开销的考虑，我们将会避免在这类机器上使用非常快的主存和互联技术。应当记住我们考虑的是数据在一个基于微内核的系统中的流动，在这种系统中，设备驱动程序、网络协议以及应用软件都可能驻留在不同的保护域中。我们相信把话题集中于此是很适合基于微内核的系统的优点的（可配置性、可分布性以及可移植性） ，也适合于当前商业领域中对这类系统的支持趋势。我们想说明的是，在不考虑操作系统结构的情况下，取得高的应用带宽也是可能的。本文讨论了工作站 CPU/存储器的带宽和网络的带宽将保持在同一个数量级，从而，网络子系统必须要致力于使网络数据在 CPU/存储器数据路径上的跳步数最小。本文也对一些应用于这些问题的技术进行了研究，得到的一个重要结论是单纯的应用这些技术对取得应用程序间吞吐率是不够的，也必须把从一个源设备，通过操作系统，到达应用程序，还可能到达终端设备的整个数据路径集成起来。本文在总结中列出了一个使端对端吞吐率得到最优化的完整数据路径。工作站硬件的性能在这一节中我们分析桌面工作站硬件影响输入输出数据流量的性能参数，包括了对目前商用工作站的测试以及下一代工作站相关参数的预测。表 1 中给出了四种商用工作站存储子系统的存储器峰值带宽（取自于硬件规格） ，以及部分 CPU/存储器带宽测量数据。存储器峰值带宽是存储子系统在突发模式传输下能够达到的带宽。括号中给出的是测量到的带宽对峰值带宽的比例。图 1:分布式协议图表 1：一些工作站的存储器带宽表 1 中的 CPU/存储器带宽数值是使用一个普通测试台程序测算得到的。该测试台程序测试的是一组读、写、复制操作过程中支持的带宽。测试台程序用C 语言编写，在各工作站自身的 C 编译器下编译，并得到了最高级的优化，但是 C 源代码或者生成的机器代码没有针对特定机器进行改写。 “读” 、 “写” 两列测试的是对一个数组中单元素进行读（写） ，而“复制 ”列使用了两种方法测量：一种是数组元素形式的赋值，另一个是调用库函数 bcopy（） 。测试台程序使用了int 类型（32 位）和 double 类型（64 位）数组，给出的数据都是各自条件下所能取得的最佳值。测试的主要结果是标准带宽仅为峰值带宽的一小部分，特别是读带宽为峰值带宽的 15%38%，复制带宽仅为 10%19%。带宽的下降是由两方面局限性综合影响的结果：第一，编译器生成的机器代码和厂家提供的 bcopy()函数对于执行基准程序故意设定的工作是不够理想的。但是我们尽量不排除它，因为这个局限性对真实程序同样会有影响。第二，硬件强制性会限制带宽，即 CPU 能支持的带宽是有限的。尽管动态 RAM 存在很大的相关访问延迟，所有存储子系统都使用了某些形式的流水线（交叉式/页式）来获得高带宽。在传输时间中初始化延迟是比较大的，所以对于少量数据传输其平均带宽会降低。 由于传输线路宽度限制，Cache 和存储器之间的数据传输不能获得大部分的峰值带宽。由此我们得出，当前工作站的 CPU/存储器带宽不超过其网络带宽的规定量级 几百 Mbps。下一代工作站将支持 1Gbps 网络适配器，它可以以网络速率将数据传送到主存。持续增长的 CPU 速度不久将允许以该速率处理软件数据。例如，DEC公司的 Alpha 处理器首次运行，允许以 1Gbps 带宽传输数据流，每个机器字包含 1224 条可执行的 CPU 指令。然而，人们没有把希望寄托在 CPU/存储器带宽的急剧增加上。存储器峰值带宽可以通过增加存储器宽度来提高，但是，Cache 的线宽必须成比例的增加才能实质性的增加 CPU 带宽。因此，就是要找到一个理想的合适的比率，很明显如果太小就不能获得大部分的峰值带宽。另一个方法是降低传输延迟，但是动态 RAM（DRAM）的访问时间被认为已经接近其技术极限。几个最近公布的器件在 DRAM 上集成了 Cache 来降低平均访问延迟4。这些集成的二级 Cache 使用大线宽，用宽数据通路与 DRAM 相连。对于任何 Cache，其合适的比率的设定依赖于它们所处的位置。我们下边将要谈到数据 I/O 访问表现很差。因此，我们希望下一代桌面工作站的 CPU/存储器带宽和网络带宽处于同一量级。数据 Cache 的作用工作站使用 Cache 来缓冲 CPU 与主存之间的速度差。该思想是在 CPU 附近设置一个高速存储器，用来存储主存中部分数据。Cache 通过降低数据和指令的平均访问延迟来提高系统性能，也降低了在共享存储器的多处理器系统中对存储器的争夺。然而，Cache 的效果受到一些因素的影响：如 Cache 的大小和组织，数据访问的位置和处理器调度。假设系统支持处理全部应用级高带宽数据，处理数据时需要 CPU 对数据单元的每个字进行检查和可能的修改，潜在的多次访问。 （下一节将确定几个数据可能通过 CPU/存储器数据通道的原因。 ）本节讨论数据 Cache 在避免 CPU/存储器间传输上效果不明显。考虑以下重要因素：处理器调度CPU 调度可能导致在执行其它程序时插入对数据单元的处理进程，当返回重新执行时，很可能缓冲的数据已经被替换。在一个多处理器系统上，进程可能被拥有自己数据缓冲的不同的 CPU 重新调度。在处理数据单元时有几种情况会发生调度：当数据单元要被传递给另外的线程（如队列） ，处理器必须调度执行该线程；在某种协议下，队列典型性的产生在用户和系统接口处，在设备驱动的中断句柄和驱动的顶层之间；在最差的情况下，在协议层之间会产生附加队列；还有硬件中断及信号触发处理器重新调度的事件。写策略多处理器数据 Cache 通常采用写穿透策略，即每个写操作都要写回主存。写缓冲与写穿透 Cache 一起被使用来减少 CPU 回写存储器的时间。但是，许多连续写如要对一个数据单元读写每一个字时将发生仍然会造成 CPU 执行存储指令时等待。Cache 查找 Cache 实际上是索引和标记，访问 Cache 中的数据不需要虚存地址到物理地址的译码。以这种方法，从虚拟共享页来的缓冲数据若超过保护域边界就不能保持其有效，物理上标记的缓冲不存在这样的问题。但是，需要一个包含参考数据的辅助翻译缓冲（TLB）处于活跃状态。Cache 容量 数据 Cache 速度很快，容量有限。因为留在 Cache 中的数据检查和修改的过程包括读取和存储每个字，所以 Cache 必须至少是数据单元的两倍大。在实际情况下，由于 Cache 有限的连接产生线路冲突和在数据处理过程中要访问程序变量使得对 Cache 容量的要求进一步增加了。为了量化数据 Cache 处理网络数据的效果，我们进行了一些初步的实验，测量了在操作系统运转以后驻留内存的网络数据量。这个值反映了由于缓冲网络数据，避免了 CPU/存储器数据传输给用户进程带来的潜在的好处。它给出了Cache 在没有网络数据复制情况下能提供的最大好处。这些实验是在装有 Mach3.0（MK67）的 HP 9000/720 工作站上运行的。这些工作站配有 256KB 虚拟索引物理标记的数据 Cache。Mach 3.0 运行着称为via 的 UNIX 操作系统和称为 Unix Server 的用户进程。Unix Server 接收用户进程的请求 UNIX 系统调用信息，并由 Mach 的微内核来使能设备请求的的处理。到达的网络报文被微内核通过中断服务机制接收，复制并压缩为一个 Mach 信息，然后发送给 Unix Server 通过其协议栈来处理。如果一个网络报文包含的数据被另一个用户进程预定，它必须从 Unix Server 的地址空间复制到目标地址空间。由于 Mach 的 Unix server 包含了典型 UNIX 单片机上的全部网络代码，所以它接收网络数据信息并将其复制到最终用户这个过程接近于模拟了 UNIX单片机处理网络报文的过程。实验测量了在 Unix Server 将网络数据复制到其用户地址空间之前，驻留Cache 的网络数据量。如果 Unix Server 执行一个随意复制的网络数据系统，Unix Server 在复制点所能看到的在 Cache 中的驻留部分也将被接收用户进程看到。公布的结果是在关闭 UDP 校验时获得的，若打开校验， Cache 中的驻留部分将会增加，因为上下文切换的机会将降低并且校验码会导致对大量缓冲报文数据的读取。对于 Mach Unix Server 在收集数据方面的修改细节见参考文献5 。收集实验数据会出现两种情况：第一，接收处理器仅运行普通的系统程序和实验接收程序的轻负载状态；第二，接收处理器正在接收从第三方处理器快速传送的 8000 字节 UDP 报文的重负载状态。图 2 画出了 200 次测试时钟周期数的算术平均值，对比了要访问的网络缓冲数据是否全在 Cache 中和 UDP 数据包大小的关系。 “100%未命中”曲线显示在网络数据缓冲中使用全部的 Cache 线，将数据从主存读到 Cache 中需要的时钟数。注意我们测试的两种情况下的数字均超过了 100%Cache 未命中时的结果。图 2：网络缓冲数据超额访问时间在我们的定时循环中，还有三方面可可能增加时钟周期数：第一，因为 Unix Server 是一个用户进程，在定时循环发生时可能会被切换，如果这种情况发生，测量时间将会增加超过 10000 个时钟周期。这个事件反映在数据上是很明显的，所以在图像上已经被排除。第二，I/O 设备的直接存储器访问(DMA)会增加执行访存指令的时钟周期数，使得在 DMA 传输结束之前防止 Cache 访问存储器。尤其是在以太网设备使用DMA 在网卡和存储器之间传送数据这种重负载的情况下，这类影响最为明显。第三，HP720 处理器使用虚地址物理标记 Cache，在访问 Cache 时，处理器的 TLB 中应该存在其入口。实验数据表明，在 Mach3.0 环境下，如果 TLB 中没有入口，则需要 130 个时钟周期的处理时间。根据 Mach 中使用的管理 TLB重新加载的算法和网络数据缓冲的组织结构，对于一个单缓冲访问可能需要加载 4 个 TLB。图中“100%TLB 和 Cache 未命中” 曲线显示了最差情况下 TLB 和Cache 未命中所需的时钟周期数的累积值，提供了假设 DMA 在最小功效时的上限访问时间。有趣的是，重负载时要比轻负载时访问时间短。由于一个 4KB 的存储页可以容纳 1 个以上的网络缓冲，我们设定在重负载情况下将大量发送的网络数据提前加载到 TLB 存储页，以满足该特殊发送方的需要。为了减小 TLB 加载的影响，我们做了另一个实验。在定时循环之前，网络缓冲所在的存储页被加载到 TLB 中，并且特别小心的保证了在加载 TLB 时没有网络缓冲被加载到Cache。图 3：强行加载 TLB 情况下网络缓冲数据超额访问时间在图 3 中，我们发现所有的测量时间均低于“100%修改后 Cache 未命中” 曲线，并且重负载时间现在要比轻负载时间长。轻负载时间的线性程度指出与其考虑大约 72%的未命中率的已修改的 Cache 线路，不如关注 100%未命中率的未修改的 Cache 线路。实验论证了存在三个限制网络缓冲数据访问时间的重要因素：第一、其它系统设备使用 DMA 操作时，增加了对存储器访问的争夺，它将显著增加把数据调入处理器 Cache 的时间，因而增加了平均数据访问时间；第二、在物理标记 Cache 上，由于网络数据分布在多个虚存页上，这种碎片性导致了对 TLB 争夺，产生了大量的额外访问开销；最后，消除了 TLB 争夺后，我们测试平均Cache 命中率为 28%，这是 Cache 对于在 Unix Server 和用户地址空间之间传输网络数据所产生的最小的积极作用。避免数据传输前两节证明了我们的论点，即工作站的 CPU/存储器带宽应不超过网络带宽的量级，数据 Cache 在降低 CPU/存储器之间网络数据流量上收效很小。因此，为了保持来自网络设备并通过操作系统、应用程序和可能的下一级设备（如显示器）的数据通路的带宽，就要避免在 CPU 和存储器之间的频繁的数据传输。以下每个小节确定了一个潜在的在该通路上的数据传输，并简要描述了几个能够有效处理或避免它的技术，同时给出了这些技术的假设前提和局限性。设备/存储器数据传输主存与网络或设备适配器之间的数据传输。通常使用的技术是 DMA 和程控I/O（PIO） 。DMA 指 I/O 适配器不通过 CPU 直接与主存传输数据。PIO 需要处理器执行一段循环程序逐字传输主存和 I/O 适配器的数据。使用 DMA 通常可以在单总线条件下传输大的数据块，因此，获得的传输率接近主存和 I/O 总线的极限。在活跃的处理器上数据传输可以并发执行，尽管在大量 DMA 操作时会因为争夺存储器访问权使处理器等待。另外，DMA 还增加了设备适配器的复杂性。数据 Cache 经常与 DMA 传输产生不一致，这是说，图 4：X-内核中消息的实现使用 PIO 方式，在从设备输入和向输出数据的过程中 CPU 一直被占用。所获得的带宽常常仅有峰值 I/O 带宽的一小部分，这是由以下的原因导致的。适配器的控制端口和数据端口可以映射到能缓冲或不能缓冲的存储器区域内。在不能缓冲的情况下，每个 LOAD/STORE 指令都导致一个较短的（例如一个机器字）I/O 总线传输，使得支持的带宽比较低。在能缓冲的情况下，I/O 总线传输长度为缓冲线（cache line）长度，取得的带宽有所提高，但是离峰值 I/O 带宽还比较远。而且，同样要刷新高速缓冲区，以和适配器端口保持一致。然而，在某些条件下 PIO 要比 DMA 可取一些。首先，内核中进行的数据运算，如校验和计算，有时候可以和 PIO 数据流动结合在一起，节省了流向主存储器的一段路经。其次，编程控制数据从 I/O 适配器传入主存后，数据还在高速缓冲区中，如果数据在高速缓冲期间得到访问，那么就可以减少主存使用的拥塞。具有分散-收集能力对基于 DMA 方式的 I/O 适配器减小存储器拥塞是非常重要的。分散机制允许一个输入数据元存储到主存的多个不连续的区域内；收集机制允许从多个不连续的缓冲区中收集一个输出数据元。分散-收集能力允许DMA 方式从不连续的物理页帧中输入和向不连续的物理页帧输出，这样就极大简化了操作系统的物理存储管理，并有助于避免把数据复制到连续的存储区中。使用 PIO 的话，用软件就可以简单的实现分散-收集机制。网卡可能要支持在数据传入主存储器之前对数据包进行多路分派操作（demultiplexing） ，以过滤和选择数据在存储器中的位置。在最简单的情况下，网卡允许主机仅仅扫描一下数据包的头部，然后主机确定数据包分派策略以及初始化 DMA 或 PIO 方式，使数据传输到主存储器的合适位置。比较精细的网卡可以通过主机 CPU 进行编程后，只需要匹配数据包的头部就能自动识别数据包，并使用 DMA 方式将其存入主存储器的正确位置。跨域传输保护机制使得在保护域（地址空间）之间传输数据成为必要。在最简单的情况下，一个 I/O 数据流是由运行在传统的单内核系统顶层的一个应用程序进程处理的，在这种情况下，每个数据单元必须跨越用户和内核的边界。一般的，附加的用户进程，如窗口管理器和多媒体服务器，以及操作系统设计内核化的趋势，都会给 I/O 数据路径引进额外的域边界。用软件数据复制来解决数据的跨域边界传输又加剧了存储器瓶颈矛盾。许多现有的技术都是依赖虚拟存储系统来提供免于复制的跨域数据传输。虚页重映射技术（remapping）8 ，9把含有数据单元的页帧和发送域之间的映射去掉，再把它们映射到接收域。虚拟复制技术（写复制）10把要传输的页帧共享给发送域和接收域，并一直延续到共享的一方试图向共享单元写入数据时。共享虚存技术11 在两个或多个域之间引入了静态共享的缓冲区来避免数据传输。虚页重映射技术有移动的语义，但没有复制的语义，这就限制了它在某些场合的应用，如发送方以后不再需要访问已传输的数据时。虚页复制技术有复制的语义，但它只能避免对那些在传输后既没被发送方改写又没被接收方改写的数据的物理复制。这两种技术都需要仔细的实现才能达到低的延迟。切换到超级用户模式，取得对 VM 数据结构的必要锁定，改变每 1 页的 VM 映射（可能是在数个层面上） ，执行 TLB/cache 保持一致性的操作，然后返回到用户态，这些操作耗费的时间限制了能获得的性能。我们在 DecStation5000/200 平台上进行了测试，结果表明，虚页重映射还是不够快，难以维持高速网卡的带宽12。实际上，这两种技术都依赖 VM 页的大小，这就产生了另一个复杂问题。当数据单元大小和 VM 页大小不匹配时，意味着被数据单元重叠的最后一页中部分数据一直得不到利用。由于数据私有的原因，内核必须把一个新分配的缓冲页的这部分清空（例如填入 0） ，不至于使之带来关系到全局缓冲区管理和跨域数据传输的重大开销。而当接收的网络数据包报头（在数据包前部）含有必须对用户进程隐藏的敏感数据时，也会产生类似的问题。存储器页帧只能得到部分利用使得对于单位数量的数据需要更多的页面，导致物理存储开销、页面分配、重映射开销以及对 TLB 表目的需求增加。共享的 VM 技术同时避免了数据传输和相关的开销，然而，在共享的保护域中，使用这种技术可能要在保护和安全上做权衡。因为共享是静态的（一个特定的页面在同一个域集合中总是可以访问的） ，需要事先知道一个数据单元的所有接收方。有一种称为动态页面共享（dynamic page sharing,fbufs）12 的混合技术，它把页面重映射和共享式 VM 结合起来，并且探寻网络拥塞的位置，来克服这两种技术的缺陷。数据处理数据处理是指对网络数据包中的每一个数据字进行检查甚至改写的计算过程。例如加密、压缩、差错检测和校正，以及数据表示的转换等。数据处理可以用硬件或软件来实现。硬件如果能支持数据处理就可以减轻 CPU 负载，而且如果集成得比较恰当的话，还能减小存储器的使用冲突。对于某些特定的处理，例如视频压缩（解压缩） ，由于这类任务的计算非常复杂，因此短期内还必须硬件支持处理。然而，如果所有的数据处理都依赖硬件，可能会严重约束新型的高带宽的应用。软件对数据的处理一般都是彼此互相独立的，这是因为它们一般都是不同的程序模块（如协议层）的一部分。从而，每次处理的数据可能是非缓冲数据，即数据是从存储器中装入或存入存储器的。这些在 CPU/存储器数据路径上重复的传输常常占用了处理消息的绝大部分时间，以及带宽。使用一种称为集成层处理（integrated layer processing,ILP）的技术可以使这样的数据传输达到最少。ILP 是通信协议实现中避免数据处理的访存操作的一种技术。不同协议中的数据进行处理时一般将它们融合到一个流水线管道中。每个数据先装入寄存器，在寄存器中由多个数据处理层进行处理，最后再存储，所有这些操作都是在下一个数据字处理前进行的。在这种方式下，一个合成的数据处理序列处理一个数据字时仅仅从存储器向 CPU 传输一次，相反的方向也只有一次，而不是对于每个不同的层可能都要传输一次。文献13有 1 份详细的性能研究，阐明了集成化可以对性能产生重要影响。另一方面，ILP 也有一个主要的局限，即不同保护域中的程序模块要实现数据处理的集成化是非常不容易的。缓冲区管理我们把缓冲区编辑和数据处理区别开来，后者是对数据的每一个字进行检测和（或）更改，而前者可以看作是一组对缓冲区的合成操作，即创建、共享、剪切、分割、合并以及回收缓冲区。引入缓冲区“ 懒赋值” （lazy evaluation）来实现前述原语的缓冲区管理器可以使缓冲区编辑免于复制操作。该管理器提供一个抽象数据类型来表示单个邻接缓冲区的提取。这个抽象缓冲区类型的实例可以实现为一串不要求连续的内存片断。例如，X-内核用一棵树来表示消息，树的叶子对应缓冲区，最左边的叶子可以带有信息（如消息头） 。图 4 是 X-内核消息的示意图。由于缓冲区编辑常常用于网络协议的实现中，所以许多操作系统的网络子系统都使用了缓冲区管理器。这些缓冲区管理器的作用域限制在单个保护域中，且一般都在内核中。在大多数系统中，跨越域边界的数据单元需要用软件复制到一个连接的缓冲区中。接口设计应用程序接口（application programming interface,API）定义了数据在应用程序间输入和输出的语义。由该接口定义的语义是实现效率的重要组成部分。例如，考虑 UNIX 的 read()、write() 系统调用。应用程序可以在其地址空间中选择一个连续的数据缓冲区，可以是任意地址，任意大小或者对齐方式（alignment） ，并且对缓冲区拥有无限制的访问。这种低级的数据缓冲区表示使得系统要避免数据复制都是非常困难的。首先，所有基于 VM（虚存管理）技术的跨域数据传输都是在一个 VM 页的单位下进行的。如果用户的缓冲区起始和结束的地址不是页对齐的，系统就必须复制第一页和最后一页在缓冲区重叠的部分。根据用户缓冲区的大小，这样会抵消掉使用免于复制技术所带来的大部分好处。其次，write()系统调用原语的语义允许用户进程在调用返回后即可修改（重用）用户缓冲区。如果这样，系统必须要么把受影响的页复制一份，要么在系统处理完先前数据之前将用户进程阻塞。第一种方法又引进了复制操作，第二种方法可能会降低用户进程的有效 I/O 带宽。一个适宜于高效数据传输方法的 API 应该使用一种抽象数据类型来表示数据缓冲区。应用程序通过对它进行操作间接访问缓冲区类型数据，即当应用程序需要缓冲区或者在系统调用中传递（接收）缓冲区实例时，应用程序请求系统创建一个实例，并当关联的缓冲区不再需要时请求系统回收这些实例。这样系统可以完全控制缓冲区的管理，包括地址分配、对齐、传输方法等等。后面章节有关于这类 API 的建议。端对端设计这一节对 I/O 子系统的设计空间进行分析，以使在从数据源到终端设备的整个数据路径上数据相关的开销得到最优化。目的是使 CPU/存储器的数据传输最少。我们分析了设计空间中的一些典型采样点，针对每种采样点，我们分析其公平性（tradeoff） ，确定最优数据路径，并选择合适的实现技术以达到最优的数据路径。在这一节中，我们引用图 5 这样的结构图来说明数据从源到终端设备的流动过程。在这些图的下面的结构模型中，使用了一条专用的存储器总线把单级高速缓冲和主存储器连接起来。总线转换器把主存储器总线连接到单独的 I/O总线上，所有的设备都连在 I/O 总线上。图 5：不同形式的数据流：a)硬件流 b)DMA-DMA 流 c)操作系统内核流硬件流一种避免 CPU/存储器瓶颈的方法是把 CPU 和主存都从数据路径上移除。数据路径的建立和控制可以由软件进行，但是数据本身从源设备到终端设备的传输不需要 CPU 的参与（图 5a） 。设备适配器和总线都必须支持端到端的传输，适配器必须能够从总线上分离出数据并做必要的格式转化。这种方法的特征是主机系统缺少综合性。因为应用程序没有访问数据，它们受限于适配器板提供的功能。这样的结果是必须在设备适配器的复杂度和灵活性以及功能性之间进行平衡。支持固定的功能集的适配器对高带宽的应用程序的革新几乎没有帮助。另一种方式是提供部件可编程的适配器。这种方式可以通过提供特殊的处理器或者可编程电路来实现。不幸的是，这种办法本身有问题。首先，应用程序以便携的方式使用可编程设备适配器是很困难的。其次，在任何给定的时刻，因为经济上的原因，用于 I/O 适配器硬件上的技术很可能落后于主机系统。因此，依靠板外设备进行处理的应用程序不能利用主机性能升级带来的好处，除非它的性能本身完全取决于该设备的计算能力（例如网络链接速度） 。在适配器中执行这样的计算是合适的，这是因为它们不能利用处理机速度的提升带来的好处。硬件流中，I/O 子系统中的数据传输不需要任何专门的技术。但是，这里所讨论的内容可以用于适配器板的内部设计。DMA-DMA 流第二种方法是使用 DMA 方式将数据从源设备传输到主存储器中的缓冲区。主存储器缓冲区可以在操作系统的控制下被编辑，然后使用 DMA 方式（见图5b）传输到终端设备。CPU 控制着数据传输并且可能改变数据单元的大小，还可以控制信息（头部） ，但是仍然处于数据路径之外。不同于前一种方法，DMA-DMA 流除了需要 DMA 支持之外并不需要源设备或者终端设备适配器提供其他的硬件。因此，可以使用普通设备（例如磁盘） 。这种方法需要两个 DMA I/O 总线。它遵循流量不大于 I/O 总线带宽的一半。实际上，可支持的流量更低，这是因为有并发 CPU 活动导致的内存访问与由DMA 传输的内存访问竞争，尽管 I/O 总线和存储总线是分离的。这种方法想要把 CPU 从数据路径上移除需要两个关键的技术：适配器对分散-收集 DMA 的支持，一个支持对自由复制缓冲区编辑的缓冲管理器。终端设备适配器对收集式 DMA 的支持是至关重要的。回想前面提到的“懒赋值”缓冲管理器可能导致一个缓冲区含有多个不连续的碎片。如果没有收集机制的话，在将数据传送到终端设备之前，必须把数据单元复制到连续的空间。操作系统内核流现在考虑所有数据操作均处于内核权限保护之下的系统：没有用户权限的程序。很清楚，数据必须通过 CPU/数据缓冲（图 5c） ，暗示了可达到的流量限制在系统复制带宽之内。目标是把 CPU/存储器数据通信量控制在最小，也就是两个传输。解决方法是结合数据操作（如果有多余一个的话）使用，例如，ILP。注意数据操作可能包括经由 PIO 的设备间数据传送。如果一个设备既支持 DMA，又支持 PIO 的话，在这种系统中使用 PIO 效果可能更好一些。这是因为程序数据传送可能会结合其它的操作。也就是说，不是首先使用 DMA，然后从（到）主存载入（存储）数据。CPU 可能直接从源I/O 适配器载入数据并且把数据存储到终端适配器中，绕过了主存。这种方法节省了两次 DMA 总线传输，并且不会和 CPU 竞争访问主存。然而，没有了存储器访问的代价是通过 I/O 总线的载入和存储操作更慢了。哪种方法能够带来更有效率的数据路径取决于对存储器的访问和通过 PIO 对目标硬件进行 DMA 传输的性能比较。不同于前面的方法，操作系统内核流提供了对数据路径的全面的可编程性。然而，所有的操作都必须在操作系统核心中执行。应用程序和用户级服务器不能调用由内核实现的数据操作。用户级流考虑数据在内核和一个或多个用户级保护域间传送的系统。这些用户级域可能是内核化操作系统的一部分，对第三方提供服务，或者是高带宽程序的一部分。除前一部分讨论的问题之外，设计者还面临着保护边界的问题。保护边界是集成数据操作的一个障碍。因此，我们认为设计者必须保证把所有的数据操作定位在相同的域中。保护同样需要一个高效的在域间传送数据的方法。前面，我们讨论了跨域数据传输的 VM 技术。使用这种方式在两个用户级域之间传送数据是非常方便的。否则，在多数系统上实现用户间传输需要两个软件复制从源用户域到内核缓冲，另一个从内核缓冲到目标用户域。作为一种特殊的例子，用户域和内核域之间的数据传输有一种不需要额外的花费的实现。如果传输同 I/O 适配器与主存之间的数据移动结合起来。这也就是，数据是在 I/O 适配器和用户缓冲之间直接传输。然而，这种方法在用于网络 I/O 的时候也有问题。在接收端，数据传输必须推迟直至找到合适的用户缓冲区，这可能依赖于用户程序。这可能导致对网络适配器缓冲区的争夺。网络适配器是支持分离报文的，这是因为数据传输前必须决定用户缓冲区。在传输端，需要有一份数据复制用于重传，但是数据的唯一复制在用户缓冲区中。最终，一个以此方法作为唯一的跨域数据传送实现而建立的系统受限于一个单一的操作系统结构，并且数据只能在单用户域内传送。需要集成API，跨域数据传送的工具，缓冲管理器，必须以一种重新审视内部精妙交互的方式集成。举例来说，一个缓冲管理器被限制在内核域之中的系统，一个用于跨域数据传送的虚拟复制工具，一个 UNIX 风格 API 指定了一个指向一片连续的用户地址空间的指针。在这种情况下，源设备的数据单元被放在了主存缓冲区中，一些缓冲区编辑作为内核 I/O 处理（例如，网络包的重新组装） 。当一个由“懒赋值” 缓冲代表的数据单元到达用户/内核边界时，它必须被赋值（把它复制到一个连续的存储区域） ，尽管使用的是虚拟复制工具。原因是接口把数据缓冲定义为连续的。因为 API 允许应用程序指定任意的缓冲地址和大小，缓冲的首尾地址可能并不对齐页边界。因此，数据传送工具必须复制与缓冲区重叠的首尾页。一旦使用域的话，可能会有更多的缓冲区编辑操作。因为用户级别是不能够得到缓冲管理工具的，应用程序要么复制数据，要么是用它的“懒赋值” 管理缓冲。后一种情况，当数据跨越域边界的时候，需要另一份数据复制。当数据被传送到内核之后，API 允许用户程序立即重新使用数据缓冲区，可能要使用虚拟复制工具复制部分缓冲区。我们认为，尽管使用了避免复制技术，数据路经上还是有多份数据复制，这是技术集成不力的人为后果。我们的问题是缓冲管理器是在内核域实现的；需要有一个全局的实现以使得在整个数据路径上一直使用懒散估算代表数据缓冲区。一个全局的抽象缓冲类型有益于所有的域（包括应用程序）来执行免复制缓冲区编辑。第二问题是关于 API 的，它通常不允许不连续的缓冲区表示，也因此，妨碍了高效的数据传送。潜在的第三个问题是，跨域数据传输工具在支持非连续缓冲碎片传送方面的先天不足。图 6：免于复制的技术之间的相关性图 6 显示了一些免于复制的技术之间的相关性。方块代表可能在数据路径上发生复制的情形，气泡是相应的免于复制的技术。箭头代表满足达到高效数据路径技术之间的相关性。举例来说，数据传输的 VM 技术，API 数据传递，缓冲管理器必须在通用的缓冲区表示上达成一致。虚线表示我们刚才不知道如何高效地集成 ILP，API 和数据传送工具以使得跨保护域的数据操作的集成。总的来说，必须在整个路径上保持“懒赋值” 数据缓冲区表示。这意味着所有的程序必须处理缓冲区表示的问题。因此，需要一个全局的缓冲管理器与API 以及跨域数据传输工具集成。跨域数据传送方法的选择可能对网络适配器的设计也有影响。举例来说，共享 VM 需要在将数据从适配器传送到主存之前首先分离。集成的数据路径这一部分建议一个建立在抽象缓冲区类型上的 API，它允许集成 API，缓冲管理器和跨域数据传送工具以达到一个高效的端到端数据路径。这个方法的关键是一个被称之为 IODATA 的抽象数据类型。这部分对 IODATA 数据类型的设计给出一个概述，讨论它的使用，简要地说明如何使用不同的缓冲管理机制和跨域数据传送工具来实现它。一个 IODATA 的实例代表任意长度的数据缓冲区的抽象。他封装了一个或者多个含有数据的物理缓冲区。在