Onload 是 Solarflare 公司开发的加速的网络中间件。它在用户空间实现了 TCP/IP 网络协议栈，能在用户空间直接访问（安全的）网络适配器硬件访问权限硬件。网络数据可以直接在网络和应用之间收发，而不必通过操作系统，这种技术称为“内核旁路”。
内核旁路（kernel bypass）可避免系统调用、上下文切换以及中断打断，从而提高应用程序代码执行效率。这也直接减少了主机处理开销，通常能够节省一半左右，为应用程序处理留出更多的CPU时间。这对于网络密集型应用程序效果最为明显，例如：
市场行情和交易应用程序
- 计算流体动力学（CFD）
- HPC（高性能计算）
- HPMPI（高性能消息传递接口），Onload兼容使用MPICH1和2、HPMPI、OpenMPI和SCALI
- 其他并行计算的物理模型
- 高带宽视频流
- Web 缓存、负载平衡和 Memcached 应用程序
- 内容加速网络（CDN）和 HTTP 服务器
- 其他系统热点，如分布式锁管理器或强制序列化点
Onload 库在运行时使用标准 BSD 套接字 API，这意味着不需要对应用程序任何修改即可进行加速。Onload 是第一个也是唯一一个提供完整内核旁路 的POSIX套接字的产品。
和传统网络对比
当使用传统网络时，应用程序调用操作系统内核向网络发送数据和从网络接收数据。从应用程序到内核的切换代价高，并且可能成为重要的性能瓶颈。当使用 Onload 加速的应用程序需要发送或接收数据时，它不需要访问操作系统，而是可以直接访问网络适配器上的分区。
传统模型的一个重要特征是，应用程序不能直接访问网络硬件，因此不能损害系统的完整性。Onload 能够通过在硬件级别将 NIC 划分为多个受保护的“虚拟NIC”（VNIC）来保持系统完整性。应用程序可以被授予对 VNIC 的直接访问权限，而无需访问系统的其余部分（包括不属于该应用程序的其他 VNIC 或内存）。因此，在 Solarflare NIC 上使用 Onload 可以在不影响安全性或系统完整性的情况下实现最佳性能。
总之，Onload 可以显著降低网络处理开销。
onload 如何提升性能
Onload 可以通过降低 CPU 开销，提升延迟、带宽和程序扩展性性能，显著降低与网络相关的开销。
开销
从用户空间应用程序转换到内核和从内核转换到内核是一项相对昂贵的操作，这通常需要执行数百或数千条指令。对于传统的网络，每次应用程序发送和接收数据时都需要这样的转换。使用Onload，TCP/IP 处理可以完全在用户进程内完成，从而消除了昂贵的应用程序/内核转换，即系统调用。此外，Onload TCP/IP 协议栈经过高度优化，进一步节省了开销。
Onload 节省的开销意味着应用程序可以使用更多的 CPU 计算能力来完成有用的工作。
延迟
按照惯例，当服务器应用程序准备好处理事务时，它会调用操作系统内核来执行“接收”操作，在该操作中，内核会将调用线程“休眠”，直到来自网络的请求到达。当这样的请求到达时，网络硬件“中断”内核，内核接收请求并“唤醒”应用程序。
所有这些开销都需要占用CPU周期以及增加缓存和页表缓冲（TLB）的空间。使用 Onload，应用程序可以保持在用户级别，等待请求到达网络适配器并直接处理它们。消除内核到用户的转换、中断以及随后的用户到内核的转换可以显著降低延迟。总之，降低开销意味着降低延迟。
带宽
由于 Onload 的开销较小，它每秒可以处理更多字节的网络流量。除了为万兆网络设计的经过特殊优化的缓冲和算法外，应用程序使用 onload 可以显著提升网络带宽。
可伸缩性
现代多核心系统能够同时运行许多应用程序。然而，当多个内核在单个资源上竞争时，这些优势可能会很快丧失，例如内核网络堆栈或设备驱动程序中的锁。这些问题在具有跨多个 CPU 内核的多个缓存和非统一内存体系结构的现代系统上更加复杂。
Onload 的使用使得网络适配器被分成不同的分区，并且每个分区都由 TCP/IP 协议栈的独立副本访问，从而实现增加 CPU 数量确实可以使吞吐量有相应的增加。
onload 透明性
Onload 在不需要重写或重新编译用户应用程序的情况下显著提高了性能，同时保留了与标准TCP 和 UDP 协议的完全互操作性。
在常规内核 TCP/IP 体系结构中，应用程序动态链接到 libc库。该操作系统库通过一组“包装器”函数为标准BSD套接字API提供支持，这些函数的实际处理发生在内核级别。Onload 也支持标准的 BSD 套接字 API。然而，与内核 TCP/IP 相比，Onload 将协议处理从内核空间转移到用户级Onload 库本身。
当网络应用程序调用标准的 socket API 函数调用时，例如 socket（）、read（）和 write（）等，这些调用会被 Linux 上使用 LD_PRELOAD 机制的 Onload 库截获。在每次函数调用中，Onload 都会检查文件描述符，使用 Solarflare 接口的套接字由 Onload 堆栈处理，而那些不使用 Solarflare 接口的套接字则透明地传递到内核堆栈。
onload 堆栈
Onload 堆栈是 TCP/IP 堆栈的一个实例。堆栈包括传输和接收缓冲区、连接以及相关的端口号和堆栈选项。每个堆栈都关联了一个或多个虚拟NIC（通常为每个使用的物理端口创建一个 NIC）。
在正常使用中，每个加速进程都有自己的 Onload 堆栈，由该进程创建的所有连接共享。多个进程也可以共享一个 Onload 堆栈实例，单个应用程序也可以具有多个 Onload 栈。
虚拟网络接口 VNIC
Solarflare 网络适配器每个网络端口上支持 1024 个传输队列、1024 个接收队列、1024 个事件队列和 1024 个定时器资源。一个 VNIC（虚拟网络接口）是由一组这些资源组成，允许 VNIC 客户端，即Onload堆栈独立、安全的发送和接收网络数据。通过网络适配器上的 IP/MAC 过滤表和接收侧调整机制（RSS）将接收到的数据包传输到指定的 VNIC。Onload 堆栈为每个 Solarflare网络端口分配一个 VNIC，因此它在用户模式下有一个专用的发送和接收通道。
重置 Solarflare 网络适配器驱动程序后，将重新安装所有虚拟接口资源，包括 Onload 堆栈和套接字。重置操作对应用程序是透明的，但在重置过程中流量会丢失。
功能概述
当建立其第一个套接字时，应用程序被分配一个 Onload 堆栈，该堆栈分配所需的 VNIC。
当数据包到达时，适配器中的 IP 过滤会识别套接字，并将数据写入相应的 Onload 堆栈中的下一个可用接收缓冲区。然后，适配器将一个事件写入由 Onload 管理的“事件队列”。如果应用程序定期进行套接字调用，则 Onload 会定期轮询此事件队列，然后直接处理事件而不是通过中断来获取这些数据。
用户级处理显著减少了内核/用户级上下文切换，并且只有在应用程序阻塞时才需要中断，因为当应用程序进行套接字调用时，Onload 一直在处理接收新的网络事件的事件队列。
混合网络适配器
服务器可以配备 Solarflare 网络接口和非 Solarflare 的网络接口。当应用程序加速时，Onload读取 Linux 内核路由表（Onload 只考虑内核默认路由表），以确定需要哪个网络接口来进行连接。如果需要非 Solarflare 接口才能到达目的地，Onload 将把连接传递到内核 TCP/IP 堆栈。无需额外配置即可实现，因为 Onload 通过查找 IP 路由表自动实现。
最大网络接口数
最多可以向 Onload 驱动程序注册 32 个网络接口。
默认情况下，Onload 每个堆栈最多支持 8 个网络接口。此限制可以是通过更改 src/include/CI/internal/transport_config_opt.h 头文件 中的 CI_CFG_MAX_INTERFACES 更改，更改后需要重新编译并安装 Onload。
黑名单/白名单
从 Onload 201502 开始，用户可以选择哪些 Solarflare 接口为 Onload 使用。
intf_white_list Onload 模块选项是一个以空格分隔的 Solarflare 列表，记录 Onload 将用于网络 I/O 的网络适配器接口。文章来源：https://www.toymoban.com/news/detail-742903.html
- 白名单中标识的接口将始终由 Onload 加速
- 未在白名单中识别的接口不会被 Onload 加速
- 空白白名单意味着所有 Solarflare 接口都将加速
intf_black_list Onload 模块选项是一个以空格分隔的Solarflare网络适配器接口列表，Onload不会将其用于网络 I/O。当一个接口同时出现在两个列表中时，黑名单优先。Onload 启动后对接口的重命名不会反映在访问列表中，对列表的更改只会影响在这些更改后创建的 Onload 堆栈，而不会影响当前正在运行的堆栈。可以在 /etc/modprobe.d 目录中用户创建的文件中指定 Onload 模块选项：文章来源地址https://www.toymoban.com/news/detail-742903.html
options onload intf_white_list=eth4
options onload intf_black_list="eth5 eth6到了这里，关于【高性能网络协议栈】openonload 篇的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
