常清宜,龚博雅,鲁克文,2,陶 丹

1(北京交通大学 电子信息工程学院,北京 100044)

2(中国电子科技集团第十五研究所,北京 100026)

1 引 言

地面相控阵雷达作为现代雷达的一个重要分支,充分利用了相控阵天线的特点,具有很多传统机械雷达所不具备的优势[1].在气象预报、资源探测、环境监测、空中管制等诸多方面体现了很好的应用潜力.地面相控阵雷达数据流具有传输速度快、单帧数据量大的特点,其单通道的传输速率一般不低于5Gb/s,单帧雷达数据帧的大小为64KB,而当前的硬件设备对于巨型帧的传输支持有限,难以支持完整雷达数据的传输.因此,地面相控阵雷达数据流在传输和使用的过程中尚需要进行复杂的分割和重组过程.这也给地面相控阵雷达数据流传输带来了极大的挑战.

传统的雷达数据流传输多采用定制化的硬件设备实现,其优点是性能比较好,但缺点是其功能相对固定、可扩展性差,且成本较高.因此,如何基于软件方法以较低的成本实现地面相控阵雷达数据流的高性能传输是十分有必要的.

基于软件的数据传输方法十分丰富,其中Linux网络协议栈最为经典.许多基于软件的现代数据传输技术如SOCKET编程和多种网络传输库(Asio,Muduo等)都采用了Linux网络协议栈作为其底层实现[2].目前,基于Linux网络协议栈的网络传输技术已经被广泛的使用.Kayum S N等人[3]使用基于Asio的高性能计算软件框架GeoDRIVE来传输大规模的地震数据流.实验结果显示,GeoDRIVE可以支持在32000个核心上同时进行2500个地震实验,并且能够处理跨多个节点发生的故障,具有较强的弹性和可扩展性.Klein D等人[4]将Asio与Libfabric和ZeroMQ进行比较,结果显示在消息的大小逐渐增加的过程中,Asio的数据吞吐量是三者中最高的,对CPU资源的消耗处于三者中的中间位置.

Linux网络协议栈具有较强的通用性,使其对于大多数常见的数据传输任务都可以胜任.但是,Linux网络协议栈因为锁、上下文切换、中断、用户态与内核态切换、内存拷贝等因素,耗费了大量CPU时钟周期,使得硬件性能得不到充分的利用,难以完成传输速率较高、传输流量较大的数据传输任务[5].

由此,Intel公司开发了DPDK[6].DPDK技术的核心优化思想在于绕开Linux内核繁琐的处理流程.相对于传统的Linux内核数据处理方式,DPDK借助VFIO(Virtual Function I/O,虚拟功能I/O)等技术,屏蔽了硬件中断,减少了内核态中的诸多操作带来的性能影响[7].同时,DPDK采用了大页机制,减少了处理数据报文时因缓存丢失带来的开销[8].DPDK也提供了RSS和Flow Director等网卡多队列技术的具体实现,通过使用这些技术可以充分利用网卡的多队列优势,实现多核并行的数据处理[9].

所以,DPDK在需要高性能、低延迟等具有较高要求的场合具有极大的应用前景.Furukawa M等人[10]将DPDK技术应用于基于远程GPU节点的分布式深度神经网络计算,使用DPDK来传输神经网络的梯度数据,相比于采用标准TCP传输方案,采用DPDK方案带来了2.2～2.5倍的加速效果.Lai L等人[11]基于DPDK框架设计了一种新的中间件UDPDK,UDPDK简化了DPDK的开发过程,提供了标准的通信接口,用于加速基于UDP的数据传输过程.实验结果显示,采用UDPDK方案时,端到端延迟减少了69%.

考虑到地面相控阵雷达数据流传输时的高性能要求,本文基于Intel DPDK技术提出了一种面向地面相控阵雷达数据流的传输机制.该机制首先针对服务器CPU单核频率低的问题提出了基于多核心CPU多线程方法,该方法将具体任务进行分解后交由多个线程处理,然后通过Ring和Mempool结构进行线程间的数据交换.其次,针对雷达数据重组和消费问题提出了高速组帧和数据消费方法,该方法通过帧池和帧索引池实现了雷达数据重组并基于DPDK进程间通信机制设计了进程间通信协议,完成了数据消费过程.最后,为了保证数据网络传输的可靠性,提出了网络报文缓冲方法,该方法结合了Mbuf和Mempool数据结构实现了对网络报文的高效管理.

2 总体方案

本文提出的面向地面相控阵雷达数据流的传输机制要求能够在高速的网络环境中实现对地面相控阵雷达数据流的转发、接收和本地消费.针对如上需求,本文设计了3个模块分别实现了以上功能,并根据服务器的职能将服务器分为接入服务器和计算服务器,其中接入服务器负责雷达数据流的转发,计算服务器搭载GPU用于运行雷达应用程序对雷达数据进行处理.总体数据处理流程如图1所示,其中各模块的详细介绍如下:

图1 整体处理流程图Fig.1 Overall processing flowchart

1)数据网络转发模块

由于数据源发送数据时其目的IP地址、端口号、MAC地址等定位信息是固定的,为了使计算服务器能够消费指定通道的数据,必须通过软件的方法改变数据包定位信息,使其顺利到达指定计算服务器.本模块通过多张独立的网卡接收不同通道的数据.成功从网卡上获取到数据后,数据网络转发模块将数据进行UDP协议的填充,并将填充完毕之后的数据进行发送.发送时采用大带宽网卡以减少对服务器硬件PCIe接口的占用,发送时将不同通道的数据并行发往该网卡的不同队列中,充分利用了大带宽网卡的性能.

2)数据网络接收模块

对于多路雷达数据流,转发时采用的是同一张网卡,在网络传输过程中会产生多路数据混杂的现象,所以在下一步处理之前必须对多路雷达数据流进行区分.本模块采用Flow Director技术实现了对于多路数据的分离.该模块首先向网卡硬件写入流匹配规则用于区分到达同一张网卡的多路雷达数据,随后从网卡的不同队列上接收数据网络转发模块发送的雷达数据,成功接收到数据后进行组帧处理.

3)数据本地消费模块

雷达数据重组完毕后需要将重组后的数据传递给雷达应用程序进行处理,所以需要一个中间件实现雷达数据的传递过程.本模块通过数据获取接口不断的从数据网络接收模块获取完整的雷达数据帧,若此时没有需要数据的应用程序,则将数据帧丢弃.若有,则通过进程间通信接口按照既定的通信协议将数据推送给应用程序,应用程序收到数据后进行相应的雷达信号处理.

3 基于多核CPU的多线程方法

由于性能要求较高,若在同一个CPU核心上完成每个模块对应的任务,虽然能够减少多核处理器的核心之间共享临界资源和线程间通信所带来的性能损耗,但是较低的单核频率无法满足性能要求,若采用较高单核频率的CPU又会极大增加成本.

为了充分利用CPU多核优势,提高系统的整体性能,本文设计了一种适用于多核CPU的多线程方法,该方法通过将任务分解为不同子任务,并借助CPU亲和性技术将任务执行线程与具体的CPU核心进行绑定,使得任务线程和CPU核心呈现1:1的关系,以减少系统自动调度CPU核心带来的上下文切换损失.对于每一个线程使用的内存空间也按照其对应的CPU核心所在的NUMA节点进行分配,减少了CPU中断、资源竞争和跨NUMA节点访问内存对性能带来的影响.具体而言,本文将数据网络转发模块以及数据网络接收模块的任务进行了如下的分解:

1)数据网络转发模块

本文将数据网络转发模块的转发任务分解成为数据获取、协议填充和数据发送3个子任务,其中数据获取子任务对CPU资源消耗较高,若CPU资源不足容易出现丢包的情况,所以数据获取子任务交由一个单独的线程完成.由于协议填充子任务对CPU资源消耗较低,所以将协议填充子任务和数据发送子任务交由一个线程执行.

2)数据网络接收模块

将数据网络接收模块的数据接收任务分解成为数据获取和数据组帧两个子任务,和转发任务中的设计一致,数据获取子任务交由一个单独的线程完成.而数据组帧子任务同样对CPU资源具有较高的要求,所以数据组帧子任务同样交由一个单独的线程完成.

通过上述方法,服务器CPU的多核优势得到了充分利用.还需要解决在数据传输速率较高前提下的多线程间通信问题.传统的线程间的通信方法多数采用共享内存实现,多个线程共享同一片内存区域,同时使用线程安全的数据结构同步对应内存区域的索引量,而不是传输整段的数据.但是传统数据结构如C++标准库中的队列等进行数据同步时都采用锁机制实现,在高速程序中,采用锁机制会大大降低程序的性能,在极端情况下甚至会阻塞线程导致程序崩溃.

DPDK中的Ring是一种无锁队列,能够进行高速数据的传递.Ring采用头尾指针来标记生产者和消费者生产或者是消费的位置,其内部操作采用CAS指令具体实现,可避免锁的竞争机制.同时Ring支持批量入队/出队操作,只需要一次系统调用的开销就可以处理多个数据,进一步提升了数据传输性能[12].

DPDK中的内存池Mempool能够高效的管理数据,Mempool在程序初始化阶段在大页内存中分配共享内存用于保存固定大小的对象,有效避免了因为在程序运行时动态分配内存带来的性能损失.同时Mempool内部维护了一个共享的Ring结构用于存储可用对象单元的具体地址,为了减少多个CPU核心资源竞争所带来的性能损失,Mempool为每一个CPU核心分配了一定大小的缓存,当CPU核心向Mempool申请对象时,首先会从对应的缓存中获取,当缓存中没有可用对象时,才会向共享的Ring中获取对象,减少了多个CPU核心资源竞争所带来的性能损失[13].

基于队列Ring和内存池Mempool结构,本文改进了传统的线程间通信方法,改进后的线程间通信方法在进行通信之前需要在大页内存中建立相应的Ring和Mempool,创建完毕后可以使用相应的Ring和Mempool进行通信.当线程1要向线程2传递数据时,线程1会向Mempool申请内存空间,申请成功后线程1将要进行传递的数据拷贝到申请的内存空间中,同时将存有该内存空间地址的指针送入Ring中.接着线程2从Ring中取出指针,通过指针访问Mempool中指定内存空间中的数据,将数据进行一次拷贝,然后对数据进行下一步的处理.当数据处理完毕后,线程2进行内存空间的释放,即将对应的内存空间归还给Mempool,解除对Mempool中对应内存空间的占用.

4 高速组帧和数据消费方法

由于完整的地面相控阵雷达数据帧的大小高达64KB,故在实际操作的过程中需要对完整的雷达数据帧做分包处理,即将完整的数据帧分解为若干小数据包.因此,在应用程序使用之前必须完成组帧的操作,将小数据包恢复为完整的雷达数据帧.传统的组帧方法是将数据帧直接保存在数组中并通过加锁的方式来保证多线程访问时的安全性.在低速情况下这种方案可以较好的实现组帧功能,但是由于加锁操作会消耗大量的CPU时间片,这会影响组帧的性能.相控阵雷达数据帧采用帧序号的方式来区别不同的帧,为了防止数据类型的溢出,帧序号一般采用循环的方式对每一帧进行编号,当帧序号取值范围比较大时,需要消耗较大的内存空间才能保存所有数据帧.

为此,本文设计了一种基于帧池和帧索引池的高速数据组帧方法.其中帧池用于保存重组后的数据帧,采用Mempool实现,由于Mempool数据结构具有内存池的特性,只要Mempool中有空闲的空间就可以保证程序的正常运行,根据后续数据处理的快慢可以合理设置Mempool的大小以达到减少内存消耗的目的.帧索引池就是一个指针数组,用于高效管理帧池中的具体数据,通过这种方式避免了对数据的直接操作,采用指针的方式管理数据,避免了对数据直接加锁的操作,提升了数据处理效率.数据包组帧的流程主要分为以下6个步骤:

步骤1.接收线程从网卡上接收并校验数据后将数据存放在栈上的临时内存中.

步骤2.将数据拷贝到相应的用于线程间通信的Mempool中,并将数据所在的地址追加到用来进行线程中通信的队列Ring队尾.

步骤3.重复上述步骤,继续处理从网卡中接收到的剩余的数据包.

步骤4.组帧线程从Ring中取出待处理数据包的地址.

步骤5.解析数据包,得到其具体的帧序号和包序号.

步骤6.根据解析出来的帧序号和包序号,将数据包拷贝到帧池对应位置上并建立相应索引.

组帧完成后雷达应用程序需要消费完整的雷达数据帧,但由于数据网络接收程序、数据本地消费程序和雷达应用程序分别是同一台机器上运行的不同的进程,如果要进行数据的传递,需要解决两个问题:1)如何在进程间进行高效的通信;2)如何在这3个进程之间建立连接.

本文借助了DPDK中进程通信的模型实现了上述3个进程之间的通信.DPDK进程通信的模型将进程分为主进程和从进程,在主进程中,DPDK将其正在使用的内存配置的详细信息记录到内存映射文件中,包括进程正在使用的大页内存、它们映射到的虚拟地址、存在的内存通道数量等.当从进程启动时,这些文件被读取,并且EAL在从进程中重新创建相同的内存配置,以便在进程之间共享所有内存区域,多进程之间可以通过该共享内存进行通信[14].

本文设计了一套进程间通信协议用于处理各进程之间的连接的建立和断开.当应用程序需要数据时,会向数据本地消费子模块发送建立连接的请求,数据本地消费子模块接收到请求之后将对请求内容进行解析,请求的内容包括建立连接和断开连接的标志位和对应的请求或是断开的数据通道编号.

若是断开连接的请求,则停止对应通道数据的发送.若是建立连接的请求,则向应用程序发出回应,表示请求已经收到并处理完成,应用程序收到响应后,进行数据接收的相关准备工作,准备工作完毕后应用程序再向数据本地消费子模块回应,表示数据接收的准备工作已经完成,可以发送数据.而数据本地消费子模块收到应用程序的回应后将从数据网络接收模块获取对应通道的数据并发送给应用程序.

5 网络报文缓冲方法

由于本文中涉及的多个模块之间需要通过网络进行数据传递,例如数据网络转发子模块与数据网络接收子模块之间的数据传递就是通过网络进行的.而网络报文的缓冲区是保证网络报文高效传递的关键,在网络堵塞时可以保存一定量的数据,防止数据丢失.所以,实现一个高效且统一的网络报文缓冲区是十分有必要的.

总的来说,针对网络帧的元数据和数据本身存放一致与否,对网络帧的封装主要有两种方式,这两种网络帧封装方式的优缺点如表1所示.

表1 网络帧封装方式Table 1 Network frame encapsulation

出于性能考虑,本文中的网络报文缓冲区采用第1种方案实现,将网络报文保存在名为Mbuf的结构体中.Mbuf主要由4部分组成:

1)Mbuf结构区域,其中保存了Mbuf的一些基本信息,如Mbuf的大小、Mbuf的地址等.

2)头部区域,其中保存了一些控制信息,如帧内容、事件等.

3)数据区域,其中保存的就是完整的报文.

4)尾部区域,该区域是预留的空间,方便数据的扩展.

通过Mbuf结构,两个模块间可以对网络报文进行统一的管理,有利于业务的实现.为了方便管理Mbuf同时进一步提高性能,本文引入了Mempool数据结构,将Mempool与Mbuf结合使用,通过内存池Mempool来管理Mbuf.即在程序中通过Mempool创建一个Mbuf对象池作为网络报文的缓冲区,需要Mbuf对象时直接从对象池中获取,使用完毕后将Mbuf对象归还给对象池.通过这种方式一方面对内存空间进行了循环利用,减少了对内存空间的使用;另一方面避免了在程序运行过程中动态分配Mbuf对象所带来的开销,加快了数据包通过网络传输的效率.

网络报文的缓冲流程如图2所示,主要分为以下5个步骤:

图2 网络报文缓冲流程图Fig.2 Network packet buffering flowchart

步骤1.在原始报文准备好的前提下向Mempool缓冲区申请一个Mbuf对象.

步骤2.若此时Mempool缓冲区中存在空闲Mbuf对象则申请成功,否则抛出异常.

步骤3.成功申请到Mbuf对象后,将报文原始信息和元数据,如:IP地址、端口号等信息写入Mbuf对应的区域.

步骤4.将封装好的Mbuf送入网卡等待发送.

步骤5.网卡成功发送Mbuf中全部报文信息后将Mbuf空间归还给Mempool缓冲区.

6 实验分析

6.1 测试环境说明

实验环境总体由3台服务器、1台上位机和FPGA数据源组成,其中1台服务器为接入服务器,1台为监控服务器,另外1台服务器为计算服务器,上位机负责控制FPGA数据源发送雷达数据,接入服务器负责接入FPGA数据源发送的雷达数据并转发给计算服务器,计算服务器用于接收接入服务器转发的雷达数据并进行相应的雷达信号处理.监控服务器用于收集相关的性能指标并进行可视化展示,服务器具体配置如表2所示.

表2 服务器配置Table 2 Server configuration

在测试开始之前需要对相应配置进行调整以获得最佳性能,主要从以下两个方面进行调整:

1)硬件设置

关闭CPU的省电模式和超线程功能,采用CPU的性能模式,手动调整CPU频率为最高频率.

2)DPDK配置

采用1GB而不是2MB的大页内存以减少页面缓存丢失的概率,同时将CPU线程从系统线程调度器中卸载,并通过isolcpus参数隔离DPDK使用的CPU,减少CPU资源的竞争,以提高系统整体性能.

6.2 数据网络传输性能测试

本节测试首先将本文中提出的传输机制与传统的基于Linux网络协议栈的网络传输库Asio进行了网络总流量的对比.本次测试中的网络总流量定义为测试时间内流经接入服务器上发送网卡的平均流量,计算方式为测试过程中流经接入服务器上发送网卡的数据总量除以测试时间,该指标的数值越高,说明对应方法的数据网络发送性能越强.本次对比测试中每个通道的传输速率被限制为5Gb/s,测试的数据包长为1472字节,测试中不断增加数据通道数,并统计不同数据通道数下的不同方法的网络总流量.实验结果如图3所示.

图3 数据网络传输性能对比图Fig.3 Data network transmission performance comparison chart

由图3可知,当数据通道数小于等于3时本文方案和Asio都能够完成数据传输任务,网络总流量都呈现线性增长的趋势.由于本文方案采用DPDK技术作为数据传输的基础,相比于Linux网络协议栈的性能有较大提升.而本文提出的网络报文缓冲方法结合了帧数据和元数据共同存放的思想和对象池的思想,能够高效的进行网络报文的缓冲,能够有效的处理由于网络拥塞带来的丢包现象.所以,当数据通道数为4以上时,采用本文方案时网络总流量依然呈现线性增长趋势,而采用Asio方法时,网络总流量增长十分缓慢,丢包现象十分严重.数据通道数为4时,Asio已经无法满足性能要求,网络总流量仅为2,400MB/s左右.通道数增加到5时,网络总流量相比于4通道时增长率仅为13%.当数据通道数增长到6以上时,网络总流量不再增长,此时的网络总流量在2,800MB/s左右,已经达到了Asio的性能瓶颈.

为了进一步对比本文中提出的传输机制与传统方法的数据网络接收性能,本节继续对本文中的传输机制和现有方法在数据包捕获率方面进行了对比测试,本次测试中数据包的捕获率定义为计算服务器上实际接收到的数据包占数据源发送的数据包的比例,该值越大说明对应方法的数据网络接收性能越强.本次测试中对比的方法仍然是基于Linux网络协议栈的网络传输库Asio,测试采用FPGA数据源进行,测试的数据包长为1472字节,测试中不断增加FPGA数据源的输出流量,并计算不同流量下两种方法的数据包捕获率.

实验结果如图4所示,当数据源发送流量在15Gb/s以下时,本文方案和Asio网络库都能够完全捕获数据源发送的数据包.当数据源发送流量大于15Gb/s时,Asio网络库的数据包捕获率出现了下降,数据源发送流量为20Gb/s时,Asio网络库的数据包捕获率下降到了90%左右,而随着数据源发送流量的不断提高,Asio网络库的数据包捕获率急剧下降,当数据源发送流量为为40Gb/s时,Asio网络库的数据包捕获率仅为50%左右,而本文方案在数据源发送流量不断增加时,数据包捕获率接近100%.本文方案之所以能够在数据网络接收测试中表现出较高的性能,一方面得益于DPDK简单的数据包处理流程,另一方面也得益于本文引入的CPU亲和性技术,通过将线程绑定CPU核心的方式减少系统调度带来的CPU时间片的浪费,使得更多的CPU时间片能够用于数据包的处理.

图4 数据网络接收性能对比图Fig.4 Data network reception performance comparison chart

由此可见,采用本文提出的传输机制进行数据网络传输时相比于传统的网络库有较大的性能提升.在数据网络发送方面,传统网络库的数据网络发送性能瓶颈在2,800MB/s左右,而该机制能够满足不小于5,000MB/s的数据网络发送要求.在数据网络接收方面,在40Gb/s的数据源发送流量的考验下,本文方案可以保证接近100%的数据包捕获率,而传统的网络库只有50%左右的捕获率.

6.3 整体性能测试

本节测试主要针对数据流传输系统的整体运行情况进行测试.主要的实验目的就是验证组成本文提出的三大模块是否能够有机结合在一起,实现数据流传输功能.为了更加简便的获取测试结果,本文引入了Prometheus和Grafana技术实现了监控指标的获取和可视化展示[15].测试开始前在接入服务器上部署数据网络转发模块,在计算服务器上部署数据网络接收模块和数据本地消费模块并开启雷达应用程序,最后在监控服务器上部署Prometheus和Grafana服务.

本次测试中使用FPGA信号源发送雷达数据,数据发送速率为5Gb/s,数据通道数为8,单个数据包长度为1472字节,UDP格式.数据转发时,源端口号设置为8000,目的端口号从8881设置到8888.本次测试中主要收集了各通道的传输速率、丢包率等性能指标,同时也收集了测试过程中系统大页内存和CPU的使用情况.其中,各项性能指标统计如表3所示.

表3 性能测试结果统计Table 3 Statistics of performance test results

通过分析表3可知,在单通道速率为5Gb/s的前提下,通道1和通道4产生了丢包现象,丢包数分别为147和42.这是由于实验环境温度较高,而实验中采用的FPGA数据源散热较差,在长时间压力测试的情况下容易造成数据源不稳定的情况,进而造成随机丢包的现象.但全通道总计丢包数仅为189,相对于处理的海量数据包可以忽略不计,整个系统的运行较为稳定.在不考虑应用程序资源占用的情况下,测试过程中接入服务器和计算服务器总体的资源使用情况如表4所示.

表4 系统资源利用情况Table 4 System resource utilization

通过分析表4可知,得益于本文中为多核CPU设计的多线程方法,将每个子任务交由不同的CPU核心执行,降低了单核CPU的计算压力,发挥了多核CPU的优势,CPU核心的利用率达到了26%.本文中提出的传输机制中采用大页内存代替了传统内存,通过增大操作系统页面的大小减少了页面的数量,降低了缓存丢失的概率,进而降低了对内存的使用量,仅使用了6.1%的内存.本文将DPDK技术与Flow Director技术相结合,利用一张网卡的多个队列进行数据的并行传输,充分利用了网卡的多队列特性,提升了网卡带宽的利用率,测试中的网卡利用率达到了42.8%,能够适应8通道数据的传输的要求.

综上所述,在外部数据源输入的情况下,本文中提出的地面相控阵雷达数据流传输机制能够充分利用多核CPU优势、降低内存空间使用率,充分发挥网卡的硬件性能.能够在单通道速率不低于5Gb/s的情况下实现8路雷达数据的长时间稳定传输.

7 结 论

本文围绕地面相控阵雷达数据流的传输问题,首先分析了数据网络传输技术的研究现状,而后基于DPDK技术提出了面向地面相控阵雷达数据流的传输机制.实验结果显示,在同时传输8路雷达数据流时,本文提出的传输机制相比于传统Asio网络通信库在网络流量性能指标方面提升了78%.在发送流量为40Gb/s时,本文提出的传输机制相比于传统Asio网络通信库在数据包捕获率性能指标方面提升了近80%.能够支持单机不小于8路雷达数据流传输,且每路雷达数据流的传输速率不低于5Gb/s.虽然本文中提出的传输机制能够在高速的情况下完成地面相控阵雷达数据流的传输任务,但是仍然有少量丢包的情况出现,如何进一步减少丢包数量,提升数据流传输的稳定性仍需要进一步研究.