背景
目前,有大量的网络应用在处理数据包的时候只需要处理数据包头,而不会操作数据负载部分,例如防火墙、TCP/IP协议栈和软件交换机。对这类网络应用而言, 包头处理产生的开销(称为“per-packet overhead”)占了整体开销的大部分。因此,如何减少包头处理开销是优化这类应用性能的关键。
减少包头处理开销最直接的方法:减少数据包数量
如何减少包数量?
图1. LRO、UFO和TSO工作原理
为了帮助基于DPDK的应用程序(如Open vSwitch)减少包头处理开销,DPDK分别于17.08和17.11支持了GRO和GSO。如图2所示, GRO和GSO是DPDK中的两个用户库,应用程序直接调用它们进行包合并和分片。
图2. DPDK GRO和DPDK GSO
1
GRO库和GSO库结构
图3描绘了GRO库和GSO库的结构。根据数据包类型,GRO库定义了不同的GRO类型。每一种GRO类型负责合并一种类型的数据包,如TCP/IPv4 GRO处理TCP/IPv4数据包。同样的,GSO库也定义了不同的GSO类型。GRO库和GSO库分别根据MBUF的packet_type域和ol_flags域将输入的数据包交给对应的GRO和GSO类型处理。
图3. GRO库和GSO库的框架
2
如何使用GRO库和GSO库?
使用GRO和GSO库十分简单。如图4所示,只需要调用一个函数便可以对包进行合并和分片。
图4. 代码示例
为了支持不同的用户场景,GRO库提供了两组API:轻量模式API和重量模式API,如图5所示。轻量模式API应用于需要快速合并少量数据包的场景,而重量模式API则用于需要细粒度地控制合包并需要合并大量数据包的场景。
图5. 轻量模式API和重量模式API
3
DPDK GRO的合包算法
算法挑战
这就要求DPDK GRO的合包算法:
基于Key的合包算法
为解决上述两点挑战,DPDK GRO采用基于Key的合包算法,其流程如图6所示。对新到的数据包,首先按照流(“flow”)对其进行分类,再在其所在的流中寻找相邻的数据包(“neighbor”)进行合并。若无法找到匹配的流,就插入一条新流并将数据包存储到新流中。若无法找到邻居,则将数据包存储到对应的流中。
基于Key的合包算法有两个特点。首先,通过流分类来加速数据包的合并是十分轻量的一种做法;其次,保存无法合并的数据包(如乱序包)使得之后对其进行合并成为可能,故减轻了包乱序对合包带来的影响。
图6. 基于Key的合包算法流程
例如,TCP/IPv4 GRO使用源和目的Ethernet地址、IP地址、TCP端口号以及TCP Acknowledge Number定义流,使用TCP Sequence Number和IP ID决定TCP/IPv4包是否为邻居。若两个TCP/IPv4的数据包能够合并,则它们必须属于同一个流,并且TCP序号和IP ID必须连续。
4
DPDK GSO的分片策略
图7. GSO分片流程
图8. Two-part MBUF的结构
GRO库和GSO库的状态
目前,GRO库还处于一个初期阶段,仅对使用最广泛的TCP/IPv4数据包提供了合包支持。GSO库则支持更丰富的包类型,包括TCP/IPv4、VxLAN和GRE。
作者简介
胡嘉瑜,毕业于中国科学技术大学,现为英特尔软件工程师,主要从事DPDK中GRO、GSO和虚拟化方向的研发。