一种基于MIPS平台的网络性能测量架构模型设计方案

为了解决X86 平台下网络性能测量工具测量精度低,性能达不到要求的问题,本文提出了一种基于MIPS 平台的网络性能测量的软件架构设计方案。这种架构设计方案在降低模块间的耦合度,对多个CPU 进行控制以及通过硬件加速提高测量精确度方面,相比X86模式有很大的提高。

0 引言
近年来以TCP/IP 为主要协议的IP 网络飞速发展,网络规模不断扩大,网络上的流量急剧增长。由于IP 网络的特殊性,人们对其流量模型、网络行为和性能指标等都缺乏理解和精确的描述,对网络测量技术的研究也明显滞后于网络及其应用的快速发展[1] [2]。

传统的基于X86 平台的网络性能测量,存在着许多不足[3]:首先,采用的是多线程的方法来处理多任务并发测量,由于涉及到线程上下文的切换,测量数据包不能及时打收发包时间戳,而出现比较大的排队时延,影响测量的精确性;其次,任务的调度策略不够灵活,不能任意控制多个CPU,操作系统的开销较大;再次,测量数据包收发的过程中需要经过操作系统的协议栈,这也会影响打收发包时间戳的精度,造成测量的误差;最后,在X86 模式下,虽然控制部分和测量部分在软件逻辑层面上已经被分开,但是硬件处理上,二者的耦合度依然很高[4],不能解决相互依赖造成的性能问题。

1 测量模型的设计思路和组件模块
为了解决在X86 平台下,网络性能测量模型存在的种种弊端,本文提出了一种基于MIPS平台的网络性能测量架构模型设计方案[5],其中,客户端框图如图1 所示,服务器端框图如图2 所示。

图1 MIPS 模式下客户端框图/图2 MIPS 模式下服务器端框图

在MIPS 平台下,该架构模型被分为控制平面、构造平面和转发平面。控制平面绑定2个CPU(控制CPU),完成多任务的控制和算法管理功能;构造平面绑定3 个CPU(构造CPU),完成测量数据包的构造及定时功能;转发平面绑定1 个CPU(转发CPU)专门执行数据包的发送和接收功能。不同CPU 的核间通信,主要由OCTEAN SDK HAL 层的调度保序单元SSO 完成。与X86 平台下的架构相比,MIPS 平台下的架构在硬件处理的层面上将控制平面、构造平面和转发平面彻底分离,解决了不同层面之间相互依赖所造成的性能问题。在控制CPU 上,该架构模型运行Linux 操作系统和协议栈,功能包括链接管理、任务管理、线程池管理、结果管理、异常管理以及对数据包信息的计算;在构造CPU 上,直接以裸核的方式运行测量数据包的构造模块;而在转发CPU 上,同样是以裸核的方式执行数据包的发送和接收工作。在转发平面上,该架构模型用单个数据包的收发,而不是以整个任务作为CPU 调度的基本单位,并且收发测量数据包的过程不经过协议栈,从而减小了CPU处理的粒度,避免了多线程上下文切换以及穿协议栈所带来的时延误差,保证测量数据包按照任务的要求得到实时处理,提高了测量的精确度。

1.1 组件模块
组件由以下几个功能模块组成,名称与作用如下:

1.1.1 任务管理模块
任务管理模块向外壳提供接口,外壳通过该接口向组件发起测量任务。该模块用来在测量任务开始前判断系统资源是否满足测试要求。任务管理模块运行于客户端的控制平面,并为客户端中当前执行的所有任务维护一张发送任务信息表。

1.1.2 链接管理模块
链接管理模块在固定端口监听控制链路连接请求,控制链路负责在测试的主方和从方之间传递参数。该模块运行在服务器端的控制平面,并为服务器端中当前执行的所有任务维护一张接收任务信息表。

1.1.3 算法管理模块
算法管理模块主要用于完成各种算法测试包的发送与接收,以及数据挖掘的相关工作,在测试完成后相应的结果都会传递到结果管理模块。该模块分成若干个子模块,根据对实时性以及对系统资源要求的不同分别运行在控制平面、构造平面以及转发平面。其中,数据包的发送和接收模块运行在转发平面,分别负责测量数据包的发送和接收,接收模块还负责对测量过程中产生的数据进行存储。发送和接收模块的共同特点是:所执行的操作对实时性要求很高。构造测量数据包模块运行在构造平面,主要负责根据不同算法的要求构造测量数据包,并对测量数据包进行硬件定时,当到达发包时间时,将测量数据包提交给转发平面的发包模块。计算模块运行在控制平面,主要负责对测量产生的总体数据进行处理,分析出测量结果,并将结果传给测量结果管理模块。该模块对实时性没有很高的要求。

1.1.4 测试结果管理模块
测试结果管理模块接受各测量任务的测量结果,并将测量结果传递给组件外的功能模块,但不对测试结果进行任何处理,实现测试结果传送和测试结果处理展现分离。

1.1.5 测试异常管理模块
测试结果异常模块负责将各种异常反馈给外壳。

1.2 SSO 的调度机制
调度保序单元SSO 作为不同CPU 之间进行核间通信的桥梁和纽带,起着至关重要的作用。SSO 通过Grp 值来决定当前数据报文应该交给哪个CPU 处理,通过QoS 值决定数据包处理的优先级,通过tag 值判断每个数据报文所属的数据流,通过tag type 判断当前数据流的锁定情况以及是否要按序处理。

图3 SSO 中的优先级队列

如图3 所示,在本架构模型中,调度保序单元SSO 维护4 个优先级队列,每个优先级队列中都存放着若干个报文描述符。报文描述符包含了指向Work Queue Entry(WQE)的指针,而WQE 中包含了指向报文的指针。其中:

1、 QoS 0 Input Queue 存放从构造面调度给转发面任务下发报文t_work 的报文描述符(QoS 0 Input Queue 里每个报文描述符的Grp=1,表示将报文交给构造CPU 处理)。

2、 QoS 1 Input Queue 存放从构造面调度给转发面的即将发送的测量数据包以及从Rx端口接收到的所有报文(包括测量数据包和控制信令)的报文描述符(QoS 1 Input Queue里每个报文描述符的Grp=2,表示SSO 将报文交给转发CPU 处理)。

3、 QoS 2 Input Queue 存放从转发面调度给控制面的计算请求报文c_work 的报文描述符(QoS 2 Input Queue 里每个报文描述符的Grp=0,表示将报文交给控制CPU 处理)。

4、 QoS 3 Input Queue 存放协商参数以及状态信息的报文描述符(QoS 3 Input Queue里每个报文描述符的Grp=0,表示将报文交给控制CPU 处理)。

SSO 调度的原则是:如果高优先级队列中有符合调度条件且未被处理的报文描述符,优先处理高优先级的报文描述符,若高优先级队列没有符合条件的报文描述符,才处理低优先级队列的报文描述符。同一优先级队列的报文描述符根据先进先出的原则进行调度。

2 测量模型关键交互流程

2.1 CPU 之间核间通信及收发数据的一般流程

2.1.1 CPU 通过Rx 端口接收数据的一般流程

图4 CPU 通过接收端口接收数据的流程图

CPU 通过Rx 端口接收数据的一般流程如图4 所示:
1、在收到报文并且进行错误校验之后,接收端口(Rx Port)通过输入总线将报文送到输入报文单元(IPD),IPD 和输入包处理器(PIP)共享数据并共同处理输入报文。

2、PIP 在解析完报文之后,对数据进行计算,创建Work Queue Entry(WQE),并生成报文描述符。

3、IPD 从空闲池分配器(FPA)中为WQE 和报文分别分配一个缓存单元。

4、IPD 将WQE 和报文写入内存。

5、PIP 将报文描述符交给SSO 中相应的QoS 队列。

6、SSO 根据QoS 优先级、包输入的顺序、以及当前数据流的锁定情况进行调度。CPU调用cvmx_pow_work_request_sync 函数从SSO 中取出属于当前CPU 所在Grp 中具有最高优先级的报文描述符,读取报文描述符中WQE 指针,从而取出WQE 中包含的报文的指针。

7、CPU 从内存中读取报文并处理报文中的数据。

2.1.2 CPU 之间经过SSO 进行核间通信的一般流程

图5 CPU 之间经过SSO 进行核间通信的流程图

CPU 之间经过SSO 进行核间通信的流程如图5 所示:

1、CPU1 对将要发出的报文进行计算,生成相应的WQE 和报文描述符,并调用cvmx_pow_work_submit 函数,将报文描述符添加到SSO 中相应的QoS 队列。

2、CPU2 调用cvmx_pow_work_request_sync 函数从SSO 中取出属于CPU2 所在的Grp中具有最高优先级的报文描述符,读取报文描述符中WQE 指针,从而取出WQE 中包含的报文的指针,最后CPU2 对报文进行相应的处理。

2.1.3 CPU 经过Tx 端口发出数据的一般流程

图6 CPU 经过Tx 端口发送数据的流程图

CPU经过Tx 端口发送数据的流程如图6 所示:

1、CPU 产生报文,将报文保存在内存中。

2、CPU 根据报文的目的地址将报文在内存中的地址和数据偏移发送到报文输出单元(PKO)中相应的报文输出队列。

3、PKO 根据报文的地址和数据偏移将报文从内存读到PKO 的存储单元。

4、PKO 将报文从PKO 的存储单元发到Tx 端口,Tx 端口将报文发出。

2.2 建立链接及收发数据包的一般流程

2.2.1 测试链接的建立流程

图7 测试链接建立流程图

测试链接的建立流程如图7 所示:
1、外壳发起测量任务,客户端的控制平面的任务管理模块在确认有足够的资源完成测量任务之后,与服务器端的链接管理模块协商测量参数,并将设置的测量参数传给接收端。其中,客户端的控制CPU 执行图6 所示的流程,经由SSO 的QoS 3 Input Queue 将控制信令发出。服务器端执行图4 所示的流程,Rx 端口从SSO 的QoS 1 Input Queue 收到来自对端的报文,并交给转发CPU 的收包模块。

2、转发CPU 判断报文属于TCP 协议之后,该报文作为收到的控制报文经由SSO 的QoS 3 Input Queue 交给控制CPU 的链接管理模块处理,流程参见图5。链接建立之后,服务器端的链接管理模块在接收任务信息表中为当前任务建立一个表项,表项内容包括:任务ID,当前任务总测试包数,已接收的测试包数以及当前任务状态。

3、客户端的任务管理模块在发送任务信息表中为当前任务建立一个新的表项。表项内容包括:任务ID,当前任务总的测试包数,已发送测试包数以及当前任务的状态。任务管理模块根据任务的要求建立一个任务下发报文t_work(包含任务ID 及算法基本参数),将t_work 通过SSO 调度给构造CPU,其中控制CPU 经由SSO 的QoS 0 Input Queue 向构造CPU发送t_work 的流程参见2.1.2 节。

2.2.2 测试报文发送流程

图8 测试报文发送流程图

测试报文的发送流程如图8 所示:
1、在客户端的构造面上,构造CPU 根据算法的要求构造测量数据包并对每个包的发包时间进行硬件定时。当有测量数据包到达发送时间之后,构造CPU 执行图5 所示流程,将该数据包的报文描述符提交给SSO 的QoS 1 Input Queue。在转发面上,当转发CPU 有空闲时,调用cvmx_pow_work_request_sync 函数,向SSO 发送取报文描述符请求,SSO 将QoS1 Input Queue 队头的报文描述符调度给转发CPU 处理。

2、转发CPU 根据WQE 找到需要处理的测试包,打发包时间戳并且将发送任务信息表里当前任务已发包数目加1,执行图6 所示流程,将数据包从Tx 端口发出。

2.2.3 测试报文接收流程

图9 测试报文接收流程图

测试报文的接收流程如图9 所示:
1、服务器端的转发CPU 执行图4 所示的流程,Rx 端口从SSO 的QoS 1 Input Queue收到来自对端的报文并判断报文属于UDP 协议之后,该报文作为收到的测试报文直接被转发CPU 处理。首先打收包时间戳,而后在pkt_info 里保存当前数据包的信息,包括当前数据包所属任务ID,数据包索引以及发包时间戳,收包时间戳。将接收任务信息表里当前任务已收包数目加一,如已收包数目小于当前任务总数据包数且收包数目不为50 的倍数,则转发CPU 回到空闲状态,执行cvmx_pow_work_request_sync 操作,等待下一数据包的到达;

2、若当前任务收包数为50 的倍数或等于当前任务的总包数,则生成一个计算请求报文c_work(包含pkt_info 指针),执行图5 所示流程,将c_work 调度给SSO 的QoS 2 Input Queue队列。控制CPU 执行cvmx_pow_work_request_sync 操作,当读取到计算请求时,调用计算模块,对pkt_info 进行计算,并输出测试结果和异常。

3 测量模型中的接口及数据结构定义

3.1 接口定义

3.1.1 内部接口

1、测试算法管理接口

当前测试算法都实现于测试算法管理接口,如果需要扩展新的测试算法,则新增加算法并实现该接口即可,不会影响原有算法代码。

接口的内容包括:启动测试对象、停止测试对象、暂停测试对象、恢复测试对象。

这个接口是以纯虚类的方式实现的,每一个测试模块都继承它,并且都在自己的类中实现每个纯虚函数。

3.1.2 外部接口
外部接口提供测试任务管理、链接管理、测试结果管理、测试异常管理四个功能部分。

1、任务管理接口
接口的内容包括:发起测量任务、停止测量任务、暂停测量任务、重启动被暂停的任务异常接口。

2、链接管理接口
接口的内容:测试服务链接管理,负责监听来自发送方的链接。
实现的方式:使用ACE 的reactor 框架进行实现。

3、测试结果管理接口
接口的内容包括:注册结果观察者、注销结果观察者、向观察者通知结果。
实现的方式:功能接口以C 的方式实现;结果接口以抽象类的方式实现。

4、测试异常管理接口
接口的内容包括:注册异常观察者、注销异常观察者、向观察者通知异常。
实现的方式:功能接口以C 的方式实现;异常接口以抽象类的方式实现。

3.2 重要数据结构
发送端给接收端发送的测试UDP 报文:
struct udprecord {
u_int32_t num;
struct timeval snd;
u_int32_t task_id; };

接收端将接收到的UDP 报文的相关信息保存到数组struct pkt_info *packet_info:
struct pkt_info {
double snd_time;
double rcv_time;
u_int32_t num;
u_int32_t task_id;
};

任务管理模块维护的发包信息表:
struct send_table {
u_int32_t task_id;
u_int32_t total_num;
u_int32_t send_num;
u_int32_t state;
};

链接管理模块维护的收包信息表:
struct receive_table {
u_int32_t task_id;
u_int32_t total_num;
u_int32_t rcv_num;
u_int32_t state;
};

4 结论
本文提出了一种基于MIPS 平台的网络性能测量工具架构设计方案。和X86 模式相比,本文设计的架构不仅在软件逻辑上,而且在硬件处理层面上,将控制平面、构造平面和转发平面分开,解决了不同平面之间相互依赖造成的性能问题;在转发面上,以单个数据包的收发,而不是任务作为调度的基本单位,减少了由于线程切换造成的操作系统开销;同时,通过裸核的方式,避免了在X86 模式下由于测量数据包收发过程中穿协议栈所造成的误差,提高了测量的精确度。

作者:林本礼,李永利,贾 林 来源:中国科技论文在线

--电子创新网--
粤ICP备12070055号