Linux系统网络性能实例分析( 三 )


需要C/C++ Linux高级服务器架构师学习资料后台私信“资料”(包括C/C++ , Linux , golang技术 , Nginx , ZeroMQ , MySQL , Redis , fastdfs , MongoDB , ZK , 流媒体 , CDN , P2P , K8S , Docker , TCP/IP , 协程 , DPDK , ffmpeg等)
Linux系统网络性能实例分析文章插图
4、 NAPI
为了改进在繁重中断载荷条件下的 Linux网络性能 , 开发了网络设备驱动程序 API(NAPI) 。 系统的负荷可用于确定是否采用轮询(polling) 或中断机制来处理输入数据以便改进性能 。 轮询机制在中断负荷较重时可以改进性能 ,但当中断负荷较轻时会浪费 CPU周期 。 中断机制在较低的中断负荷情况下可以改进延迟 , 但当中断负荷超过了最大无损转发率(Maximum Loss Free Forwarding Rate ,MLFFR)时 , 会导致系统对于活锁(live lock)是脆弱的 。 NAPI只适用于实现了DMA缓冲区环的 NIC 。 当网络报文到达时 ,NAPI被置入环上的下一个缓冲区中 。 通常 , 对于每个报文 ,处理器都会被中断并且系统从环中清除该报文 。 当 NAPI被激活时 , 响应第一个中断 , 通知 NIC停止中断 。 然后 NAPI在环上轮询 。NAPI在处理报文过程中 , 可以取出新报文而无需更多中断 , 从而极大减少了接收中断 , 这有助于系统在繁重的网络负荷条件下正常运行 。Linux 2.5内核中的 NAPI实现使得网络设备驱动程序员无需在每个驱动程序中人工实现轮询 , 还可以管理中断泛洪 , 并保护系统免受拒绝服务(Denial of Service ,DoS)攻击 。 由于中断处理程序的 CPU开销 , 在没有 NAPI支持的情况下泛洪的最高限额要低得多 。 NAPI也消除了编制大量代码来实现NIC硬件中断缩减(interrupt mitigation)解决方案的需求 。 为了利用 NAPI的优点 , 网络设备驱动程序需要使用新的网络 API(NAPI) 。 当前 , 许多网络设备驱动程序都提供对 NAPI的支持 。 Intel Gigabit Ethernet等网络驱动程序将NAPI作为一个可构建在驱动程序中的选项 ,而诸如 BroadComTg3等驱动程序默认地支持 NAPI 。 如果网络驱动程序不使用 NAPI特性的话 , 则内核中的 NAPI代码也不被使用 。
5、 TCP卸载引擎
有些服务器应用程序并未使用LinuxTCP/IP协议的一些独有特性如IP过滤或服务质量(Quality of Service ,QoS) ,这些应用可以使用支持 TCP/IP卸载特性的网卡来改进网络性能 。 TCP卸载引擎(TCPOffloadEngine ,TOE)技术包括对现有TCP/IP协议栈软件进行扩展 , 从而能够使用在特殊 TOE网卡(TNIC)上实现的硬件特性 。 这种硬件/软件组合允许操作系统将所有 TCP/IP流量卸载到 TNIC 上的专用硬件中 , 这样就不必将服务器资源消耗在对 TCP/IP帧的处理操作上 , 而是可以将其用于满足应用程序和系统的其他需求 , 从而提高了系统的整体性能 。 这似乎是一种改进网络性能的极好方案 , 但通用的 TCP卸载解决方案却不断地失败 ,TOE只适合一些特定的应用环境 。例如 , TCP卸载机制的适用上下文包括通过商用网络硬件设备构建的存储互连结构、高性能集群解决方案等 。对千兆位以太网的工作负荷分析表明 ,系统需要 1GHz的 CPU处理能力来处理每吉比特网络流量 。 随着更高速的处理器系统、高性能串行PCI-Express系统总线、内置了检验和运算逻辑的以太网控制器以及中断缩减机制的出现 , 用户将可以在服务器中使用多条千兆位以太网连接 , 同时不会导致性能下降 。 然而 , 网络带宽的改善也与系统通过诸如TOE之类的解决方案来提高网络性能的其他部件改进保持一致 。 但由于存在着严重的性能问题 , 并且实际部署 TCP卸载机制比较复杂 , TCP卸载作为一种通用解决方案已经失败 。 学术界和产业界中对于 TOE技术都存在着支持与反对的声音 。 然而 , 除了集群和网络存储解决方案外 , 许多厂商还开发了用于其他各种工作负荷的 TNIC 。与 LinuxTCP/IP软件栈代码相比 , 各种 TOE解决方案都是专有的 , 其功能也各异 。 这些专有的 TOE方案中可能不提供某些特性如 IPCHAINS、 IPTABLES以及通用报文处理能力 。 许多开发 TNIC和驱动程序的厂商都支持多种操作系统 。 尽管早期测试结果显示在Linux上 NetBench的性能改进了 17% ,但所用的驱动程序在测试时并不稳定 ,因此需要进一步研究这种特性 。 如果驱动程序和 NIC更稳定的话 , 应该会实现更高的性能结果 。注意 TOE不同于 TCP分片卸载(TSO) 。TSO只对数据分片操作进行卸载 。 在 TSO技术中 , TCP/IP栈将应用程序传来的整个消息都封装在帧里传递给 NIC 。NIC再将数据(消息)划分为多个帧 , 为每个帧构造帧头以便进行传输 。 这种卸载操作只在发送端(输出通信)完成 , 不处理输入通信 。 而 TOE将整个 TCP/IP协议栈处理操作都卸载到 NIC上 , 包括输入和输出处理 。尽管TOE解决方案是一种改进网络性能的急需技术 ,但目前还不清楚 Linux开源社区将如何采纳该技术 。 有些人认为LinuxTCP/IP栈中已支持 Zerocopy机制 ,因此复制操作的次数已得到减少 。 采用 TOE技术所实现的多数性能收益可通过NIC中的校验和、分片卸载以及中断缩减机制来获取 , 而其余功能只执行基本的 socket管理和进程唤醒 , 因此不需要这种技术 。 如果 TOE解决方案不断改进 ,并且与软件网络栈相比能够显示出巨大优势 , 则 TOE技术的采用量可能会增加 。目前 , 只有商业公司在开发 TOE引擎 ,因此这类解决方案的实现随着厂商的不同而各异 。 厂商也许能够减少或解决TOE实现和部署中的难题 ,并改变那些不愿意承认 TOE是网络性能改进可行方案的怀疑者的想法 。 三、 示例分析 下面给出该示例分析所使用的基准测试的结果 , 并展示目前为止所讨论的各种性能增强特性的累积性能改进 。 某些基准测试捕获所有特性的累积收益 , 而另一些则捕获特定工作负荷的特定收益 。


推荐阅读