CN106549869A - 数据包处理方法及装置 - Google Patents

Abstract

本发明公开了数据包处理方法与装置，该方法包括：生成数据流句柄，其中，该句柄包括接收缓冲区和发送缓冲区；在接收数据和发送数据时分别通过传递数据的指针与接收缓冲区和发送缓冲区进行交互。通过本发明解决了现有技术中数据包通信中由于至少需要二次拷贝而导致的问题，提高了数据包通信速度。

Description

数据包处理方法及装置

技术领域

本发明涉及通讯领域，具体而言，涉及数据包处理方法及装置。

背景技术

在某些操作系统中，网卡收到数据包之后拷贝到业务进行一般需要两次拷贝。下面以Linux为例进行说明，图1是相关技术中的Linux系统UDP通信流程图，如图1所示，网卡收到数据包传递到应用层需要从网卡内存拷贝到SKB(System Kernel Buffer系统内核缓冲)，再从内核态拷贝到用户态，至少经过了二次拷贝。应用层发送数据包同样经历反向的流程。现在网卡速率最高可达40G每秒，对这些数据包进行拷贝，将会大量的消耗CPU的性能，造成通信设备在单位时间内的数据包处理能力降低，从而降低了网络传输的整体性能。

在LTE网络架构下，UDP通信迅猛增长，传统Linux的UDP通信由于至少二次拷贝消耗CPU、采用了小块内存分配，寻址时延大、采用相对低效中断机制。导致UDP通信整体时延增大、吞吐量降低，以至于无法充分利用现今万兆级的光纤通信的带宽。在这种情况下，一般通过采购昂贵的高性能硬件平台来弥补这一缺陷。

发明内容

本发明提供了数据包处理方法及装置，以解决现有技术中数据包通信中由于至少需要二次拷贝而导致的问题。

根据本发明的一个方面，提供了一种数据包处理方法，包括：生成数据流句柄，其中，所述句柄包括接收缓冲区和发送缓冲区；在接收数据和发送数据时分别通过传递所述数据的指针与所述接收缓冲区和所述发送缓冲区进行交互。

进一步地，在接收数据时，通过传递所述数据的指针与所述接收缓冲区进行交互包括：从所述接收缓冲区获取所述数据；经所述数据的指针发送给业务进程。

进一步地，在发送数据时，通过传递所述数据的指针与所述发送缓冲区进行交互包括：将所述数据的指针传递给所述发送缓冲区；根据所述指针获取到所述数据，将所述数据封装后进行发送。

进一步地，所述数据为数据包的净荷。

进一步地，通过死循环的方式读取所述接收缓冲区和所述发送缓冲区，在读取到有待接收或待发送的数据时进行接收或者发送处理。

根据本发明的另一个方面，还提供了一种数据包处理装置，包括：生成模块，用于生成数据流句柄，其中，所述句柄包括接收缓冲区和发送缓冲区；交互模块，用于在接收数据和发送数据时分别通过传递所述数据的指针与所述接收缓冲区和所述发送缓冲区进行交互。

进一步地，所述交互模块包括：获取模块，用于在接收数据时从所述接收缓冲区获取所述数据；发送模块，用于经所述数据的指针发送给业务进程。

进一步地，所述交互模块包括：传递模块，用于在发送数据时将所述数据的指针传递给所述发送缓冲区；封装模块，用于根据所述指针获取到所述数据，将所述数据封装后进行发送。

进一步地，所述数据为数据包的净荷。

进一步地，所述交互模块，用于通过死循环的方式读取所述接收缓冲区和所述发送缓冲区，在读取到有待接收或待发送的数据时进行接收或者发送处理。

通过本发明，采用生成数据流句柄，其中，该句柄包括接收缓冲区和发送缓冲区；在接收数据和发送数据时分别通过传递数据的指针与接收缓冲区和发送缓冲区进行交互。通过本发明解决了现有技术中数据包通信中由于至少需要二次拷贝而导致的问题，提高了数据包通信速度。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是相关技术中的Linux系统UDP通信流程图；

图2是根据本发明实施例的数据包处理方法的流程图；

图3是根据本发明实施例的数据包处理装置的结构框图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。

在本实施例中提供了一种数据包处理方法，图2是根据本发明实施例的数据包处理方法的流程图，如图2所示，该流程包括：

步骤S202，生成数据流句柄，其中，该句柄包括接收缓冲区和发送缓冲区；

步骤S204，在接收数据和发送数据时分别通过传递该数据的指针与该接收缓冲区和该发送缓冲区进行交互。

通过上述步骤，解决了现有技术中数据包通信中由于至少需要二次拷贝而导致的问题，提高了数据包通信速度。

作为一个可选的实施例，在接收数据时，通过传递该数据的指针与该接收缓冲区进行交互包括：从该接收缓冲区获取该数据；经该数据的指针发送给业务进程。

作为另一个可选的实施例，在发送数据时，通过传递该数据的指针与该发送缓冲区进行交互包括：将该数据的指针传递给该发送缓冲区；根据该指针获取到该数据，将该数据封装后进行发送。

上述实施例及可选实施例方式中的数据可以为数据包的净荷。

为了使处理效率更高，可以通过死循环的方式读取该接收缓冲区和该发送缓冲区，在读取到有待接收或待发送的数据时进行接收或者发送处理。

在本实施例中还提供了一种数据包处理装置，图3是根据本发明实施例的数据包处理装置的结构框图，如图3所示，该装置包括：

生成模块32，用于生成数据流句柄，其中，该句柄包括接收缓冲区和发送缓冲区；

交互模块34，用于在接收数据和发送数据时分别通过传递该数据的指针与该接收缓冲区和该发送缓冲区进行交互。

作为一个可选的实施例，该交互模块包括：获取模块，用于在接收数据时从该接收缓冲区获取该数据；发送模块，用于经该数据的指针发送给业务进程。

作为一个可选的实施例，该交互模块包括：传递模块，用于在发送数据时将该数据的指针传递给该发送缓冲区；封装模块，用于根据该指针获取到该数据，将该数据封装后进行发送。

作为一个可选的实施例，该数据为数据包的净荷。

作为一个可选的实施例，该交互模块，用于通过死循环的方式读取该接收缓冲区和该发送缓冲区，在读取到有待接收或待发送的数据时进行接收或者发送处理。

下面以Linux为例结合优选实施例进行说明。

本优选实施例基于因特尔的DPDK UDP SOCKET通信，实现一种方法，接管UDP数据包的转发过程，通过减少UDP通信过程中数据包的拷贝次数、高效的内存访问、响应迅速的死循环轮询方式。降低UDP通信的延时，达到UDP通信加速的目的。解决了传统Linux系统UDP SOCKET通信的不足，无需升级硬件平台，不增加用户成本。

本优选实施例使用因特尔DPDK驱动替代Linux操作系统的网卡驱动，DPDK网卡驱动位于用户空间，当物理网卡收到网络发送过来UDP数据包时，位于用户空间的程序可以使用DPDK驱动提供的接口直接访问数据包的指针，减少了一次数据内容拷贝。

由于本优选实施例是提高大流量UDP通信的速度，设计思想以内存空间换取低时延，因此内存访问技术采用高效的hugepage方式。避免小块内存分配，访问内存时寻址效率低的问题。

应用程序调用封装的DPDK API(应用程序接口)函数，生成一个数据流句柄，该句柄包含接收缓冲区和发送缓冲区，通过同一个句柄值，即可完成进程间通信。

应用程序在接收数据包时，本优选实施例的进程从接收缓冲区中获取数据包，剥离数据包的物理层头部、IP头部、UDP头部，然后通过数据流句柄进行进程间通信，将数据包的净荷的指针发送到业务进程，而不是通过拷贝数据包给业务进程。整个过程中，数据包都是通过指针的方式直接传递，并不是通过拷贝，也就是减少了一次数据包的拷贝。

应用程序在发送数据包的时候，将需要发送的数据净荷的指针传递到数据流句柄对应的发送缓冲区；本优选实施例的进程中有一个线程采用死循环轮询方式，不停的尝试从发送缓冲区去获取数据净荷，如果获取到数据净荷，就根据发送的地址信息，进行UDP和IP协议格式封装，通过DPDK网卡驱动提供的发送函数，把数据报包通过指定的网卡发送到网络。

在本优选实施例中：整个UDP通信过程中，数据包的接收和发送，都是直接传递数据包指针，而没有对数据进行拷贝。采用高效率的hugepage的内存方式，提高通信过程中处理数据包时，访问内存寻址效率，从而降低通信时延，达到通信加速的目的。DPDK网卡驱动，将数据包从网卡硬件缓冲区，通过DMA(直接内存访问)的方式直接映射到用户空间的内存中，用户空间进程可以直接访问数据包的指针，减少了一次网卡到内存中的拷贝。所有线程的运行方式都是通过死循环轮询的方式，与传统Linux中断响应方式相比，响应速度更快。从而降低通信时延，达到通信加速的目的。

使用本优选实施例方法进行UDP SOCKET通信加速实验。配置好通信流量收发器(能根据要求产生UDP流量的设备)，使得UDP通信数据包的发送目标IP地址为运行本优选实施例方法的通信设备(以下简称本设备)。本设备UDP通信目的地址为通信流量收发器。

启动通信流量收发器,以每秒10G速度发送UDP数据包。逐步增大发送流量。

UDP数据包通过万兆交换机到达本设备。首先DPDK网卡驱动侦测到有UDP数据包到达。进行IP、UDP解析，剥离头部，将数据包净荷的指针通过数据流句柄传递给业务接收缓冲区；业务进程读取自身接收缓冲区，根据业务需求进行逻辑处理。

业务层逻辑处理后，将数据净荷指针添加到自身进程的发送缓冲区；DPDK驱动通过数据流句柄从缓冲区获取数据净荷，进行UDP、IP封装，通过网卡发送给通信流量收发器。

从通信流量收发器观察通信带宽占用率，从本设备上观察CPU占用情况。

为方便对比，再次使用传统Linux系统内核协议栈进行UDP通信流量测试，通过2组数据对比发现：运行本优选实施例方法的设备进行UDP通信，CPU使用率比使用传统Linux内核协议栈进行UDP通信的CPU使用率低20％。随着流量增大，这一数据也相应放大。

运行本优选实施例方法的设备进行UDP通信，数据包转发延时低，速度更快。而使用传统Linux内核协议栈进行UDP通信，监测仪显示，通信速度只有本优选实施例方法通信速度的75％，随着流量增大，这一数据相应降低。原因如前所述，数据包经历了2次拷贝、采用了小块内存访问、及相对低效的中断机制。

基于DPDK网卡驱动的UDP SOCKET通信的数据包不经过LINUX内核TCP/IP协议栈，由本优选实施例实现的方法接管，由于处理流程减少了对数据包的拷贝次数，降低了CPU的消耗。使用了高效的内存访问技术和响应更快的轮询机制。使得UDP通信的时延大大降低，从而提高了使用本优选实施例方法的进行UDP通信的设备的通信速度。不需要升级硬件，不需要用户支付额外成本，大大提高产品的竞争力。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种数据包处理方法，其特征在于包括：

生成数据流句柄，其中，所述句柄包括接收缓冲区和发送缓冲区；

在接收数据和发送数据时分别通过传递所述数据的指针与所述接收缓冲区和所述发送缓冲区进行交互。

2.根据权利要求1所述的方法，其特征在于，在接收数据时，通过传递所述数据的指针与所述接收缓冲区进行交互包括：

从所述接收缓冲区获取所述数据；

经所述数据的指针发送给业务进程。

3.根据权利要求1所述的方法，其特征在于，在发送数据时，通过传递所述数据的指针与所述发送缓冲区进行交互包括：

将所述数据的指针传递给所述发送缓冲区；

根据所述指针获取到所述数据，将所述数据封装后进行发送。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述数据为数据包的净荷。

5.根据权利要求1至3中任一项所述的方法，其特征在于，

通过死循环的方式读取所述接收缓冲区和所述发送缓冲区，在读取到有待接收或待发送的数据时进行接收或者发送处理。

6.一种数据包处理装置，其特征在于包括：

生成模块，用于生成数据流句柄，其中，所述句柄包括接收缓冲区和发送缓冲区；

交互模块，用于在接收数据和发送数据时分别通过传递所述数据的指针与所述接收缓冲区和所述发送缓冲区进行交互。

7.根据权利要求6所述的装置，其特征在于，所述交互模块包括：

获取模块，用于在接收数据时从所述接收缓冲区获取所述数据；

发送模块，用于经所述数据的指针发送给业务进程。

8.根据权利要求6所述的装置，其特征在于，所述交互模块包括：

传递模块，用于在发送数据时将所述数据的指针传递给所述发送缓冲区；

封装模块，用于根据所述指针获取到所述数据，将所述数据封装后进行发送。

9.根据权利要求6至8中任一项所述的装置，其特征在于，所述数据为数据包的净荷。

10.根据权利要求6至8中任一项所述的装置，其特征在于，

所述交互模块，用于通过死循环的方式读取所述接收缓冲区和所述发送缓冲区，在读取到有待接收或待发送的数据时进行接收或者发送处理。