CN113364705B - 一种协议报文的处理方法及系统 - Google Patents
一种协议报文的处理方法及系统 Download PDFInfo
- Publication number
- CN113364705B CN113364705B CN202010153040.5A CN202010153040A CN113364705B CN 113364705 B CN113364705 B CN 113364705B CN 202010153040 A CN202010153040 A CN 202010153040A CN 113364705 B CN113364705 B CN 113364705B
- Authority
- CN
- China
- Prior art keywords
- protocol
- thread
- processing
- core
- depth
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/30—Peripheral units, e.g. input or output ports
- H04L49/3063—Pipelined operation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
- H04L49/9063—Intermediate storage in different physical parts of a node or terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种协议报文的处理方法及系统，涉及通信技术领域。协议报文的处理方法包括：多核处理器的核从流水线线程队列获取任一条流水线的链路解析线程，执行链路解析线程得到待处理的三层报文；当待处理的三层报文为协议报文时，将协议报文存入为该条流水线配置的缓存队列，并启动一个协议处理线程；一个预先配置的核执行被启动的协议处理线程，以处理协议报文，其中，预先配置的核的数量不少于流水线的数量，执行协议处理线程的时长是根据缓存队列的当前深度确定的。本发明确保协议报文得到及时处理。
Description
技术领域
本发明涉及通信技术领域，具体是涉及一种协议报文的处理方法及系统。
背景技术
多核处理器软件报文转发采用流水线模型，报文的转发流程分为不同的阶段，每个阶段为一个独立的线程，对报文执行不同的操作：接收报文、处理报文和发送报文。在流水线模型中，多条流水线的所有线程的线程函数指针都放在一个流水线线程队列(Pipeline Thread queue，PLTQ)中。处理器的多个核(core)公平地从PLTQ中获取线程函数指针并执行线程，执行完线程后，将线程函数指针放回PLTQ中，整个线程调度就是循环进行取线程、执行线程和放回线程。
在流水线模型中，承载用户数据的数据报文以及建立和维护网络信道的协议报文混合在一起，在多个转发流程的线程中被处理。当报文流量较大，超出线程处理能力时，就会造成数据报文和协议报文一起丢失，而协议报文丢失会引起业务振荡。
发明内容
针对现有技术中存在的缺陷，本发明的目的在于提供一种协议报文的处理方法，确保协议报文得到及时处理。
一种协议报文的处理方法，其包括：
多核处理器的核从流水线线程队列获取任一条流水线的链路解析线程，执行链路解析线程得到待处理的三层报文；
当待处理的三层报文为协议报文时，将协议报文存入为该条流水线配置的缓存队列，并启动一个协议处理线程；
一个预先配置的核执行被启动的协议处理线程，以处理协议报文，其中，预先配置的核的数量不少于流水线的数量，执行协议处理线程的时长是根据缓存队列的当前深度确定的。
在上述技术方案的基础上，
所述预先配置的核在执行周期的指定时长内执行被启动的所述协议处理线程，指定时长根据所述缓存队列的当前深度所对应的深度级别预先设定，深度级别是对所述缓存队列的深度范围分级得到的。
在上述技术方案的基础上，
多核处理器的所有核均为所述预先配置的核，每个所述预先配置的核与一个所述协议处理线程绑定；
所述指定时长在所述执行周期中的初始占比随着所述深度级别的递增而增加，初始占比均小于100％并保存在线程分配表中，线程分配表还包括核与绑定的所述协议处理线程的关联信息以及所述协议处理线程的启动信息。
在上述技术方案的基础上，
根据所述缓存队列的当前深度计算实时平均深度，在所述线程分配表中按照判定条件选择并启动一个未被启动的所述协议处理线程；
所述判定条件包括：
所述协议处理线程对应的所述深度级别匹配实时平均深度；
所述协议处理线程对应的所述深度级别高于实时平均深度；
将所述缓存队列上次启动的所述协议处理线程的所述初始占比更改为100％。
在上述技术方案的基础上，
所述执行协议处理线程的时长根据所述缓存队列的当前深度动态调整。
与此同时，本发明的另一个目的在于提供一种协议报文的处理系统，确保协议报文得到及时处理。
一种协议报文的处理系统，设于多核处理器中，所述系统包括：
至少一个缓存队列，每个缓存队列配置给一条流水线；
数据报文处理模块，其设于每个核中，用于从流水线线程队列获取任一条流水线的链路解析线程，执行链路解析线程得到待处理的三层报文；当待处理的三层报文为协议报文时，将协议报文存入为该条流水线配置的缓存队列，并启动一个协议处理线程；
协议报文处理模块，其设于预先配置的核中，预先配置的核的数量不少于流水线的数量，协议报文处理模块用于执行被启动的协议处理线程，以处理协议报文，其中，执行协议处理线程的时长是根据缓存队列的当前深度确定的。
在上述技术方案的基础上，
所述协议报文处理模块用于在执行周期的指定时长内执行被启动的所述协议处理线程，指定时长根据所述缓存队列的当前深度所对应的深度级别预先设定，深度级别是对所述缓存队列的深度范围分级得到的。
在上述技术方案的基础上，
多核处理器的所有核均为所述预先配置的核，每个所述协议报文处理模块与一个所述协议处理线程绑定；
所述指定时长在所述执行周期中的初始占比随着所述深度级别的递增而增加，初始占比均小于100％并保存在线程分配表中，线程分配表还包括核与绑定的所述协议处理线程的关联信息以及所述协议处理线程的启动信息。
在上述技术方案的基础上，
所述协议报文处理模块用于根据所述缓存队列的当前深度计算实时平均深度，在所述线程分配表中按照判定条件选择并启动一个未被启动的所述协议处理线程；
所述判定条件包括：
所述协议处理线程对应的所述深度级别匹配实时平均深度；
所述协议处理线程对应的所述深度级别高于实时平均深度；
将所述缓存队列上次启动的所述协议处理线程的所述初始占比更改为100％。
在上述技术方案的基础上，
所述执行协议处理线程的时长根据所述缓存队列的当前深度动态调整。
与现有技术相比，本发明实施例协议报文的处理方法包括：多核处理器的核从流水线线程队列获取任一条流水线的链路解析线程，执行链路解析线程得到待处理的三层报文；当待处理的三层报文为协议报文时，将协议报文存入为该条流水线配置的缓存队列，并启动一个协议处理线程；一个预先配置的核执行被启动的协议处理线程，以处理协议报文，其中，预先配置的核的数量不少于流水线的数量，执行协议处理线程的时长是根据缓存队列的当前深度确定的，确保协议报文得到及时处理。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例协议报文的处理方法流程图；
图2是本发明实施例一个核的线程执行示意图；
图3是本发明实施例多核处理器的线程执行示意图；
图4是图3中协议报文的线程执行示意图；
图5是本发明实施例在执行周期内的时长分配示意图；
图6是步骤S120的流程图；
图7是本发明实施例一个核的线程执行流程图；
图8是本发明实施例协议报文的处理系统示意图。
具体实施方式
下面结合附图及具体实施例对本发明作进一步的详细描述。
参见图1所示，本发明实施例提供一种协议报文的处理方法，应用于多核处理器，协议报文的处理方法包括：
S110多核处理器的核从流水线线程队列(PLTQ)获取任一条流水线的链路解析(Link Resolution，LINK)线程，执行链路解析线程得到待处理的三层报文。
S120当待处理的三层报文为协议报文时，将协议报文存入为该条流水线配置的缓存队列，并启动一个协议处理线程。
S130一个预先配置的核执行被启动的协议处理线程，以处理协议报文，其中，预先配置的核的数量不少于流水线的数量，执行协议处理线程的时长是根据缓存队列的当前深度确定的。
路由器所支持的报文类型，通常包括但不限制于以下报文类型：
a)从二层封装来看，包括：高级数据链路控制(High-Level Data Link Control，HDLC)、点对点通信协议(Point to Point Protocol，PPP)、帧中继(Frame Relay，FR)、以太网(Ethernet，ETH)等。
b)从三层封装来看，包括：互联网控制报文协议(Internet Control MessageProtocol，ICMP)、互联网组管理协议(Internet Group Manage Protocol，IGMP)、网际协议第四版(Internet Protocol version 4，IPv4)、IPv6、传输控制协议(TransmissionControl Protocol，TCP)、用户数据报协议(User Datagram Protocol，UDP)、多协议标签交换(Multi-Protocol Label Switching，MPLS)、通用路由封装协议(Generic RoutingEncapsulation，GRE)和第二层隧道协议(Layer Two Tunneling Protocol，L2TP)等。
数据报文通常指承载用户数据的报文，主要有IPv4和IPv6报文。协议报文：通常指建立和维护网络信道的开销报文，包括但不限于：地址解析协议(Address ResolutionProtocol，ARP)、PPP和HDLC的保活(Keep alive)报文、STP、ICMP、IGMP、动态主机配置协议(Dynamic Host Configuration Protocol，DHCP)、链路状态报文(Link State PDU，LSP)、中间系统到中间系统(Intermediate System To Intermediate System，IS-IS)、开放最短路径优先(Open Shortest Path First，OSPF)、双向转发检测(Bidirectional ForwardingDetection，BFD)、边界网关协议(Border Gateway Protocol，BGP)和路由信息协议(Routing Information Protocol，RIP)等。
报文从端口进来，端口包括物理(Physical，PHY)层、媒体访问控制(Media AccessControl，MAC)和报文协处理器，由报文协处理器将报文写到存储器中，并将报文在存储器中的地址存放在端口对应的报文描述符环形链表(Buffer Description，BD)，BD通常由报文协处理器管理。
在本发明实施例中，报文的转发流程分为四个不同的阶段：RX→LINK→IPserv→TX，每个阶段由独立的线程执行，对报文执行不同的操作，其中，接收RX(Receive)线程从硬件接收报文，从报文协处理器的BD环中读取报文在存储器中的地址；LINK线程进行二层封装解析；发送TX(Transmit)线程将报文封装二层头从指定端口发送出去。
在每条流水线的LINK阶段，分别按一定规则，识别协议报文，入队到缓存队列，识别数据报文存入存储区域，然后在互联网协议服务IPServ(Internet Protocol Service)阶段分别处理报文三层信息，进行路由转发和报文响应处理。
参见图2所示，IPserv阶段包括数据处理(IPserv-data)线程和协议处理(IPserv-protocol)线程，IPserv-data线程用于处理数据报文，IPserv-protocol线程用于处理协议报文。使得协议报文和数据报文由不同的线程来处理，并且所有的线程都由中央处理器(Central Processing Unit，CPU)的多个核来执行。
在流水线模型中，n条流水线的RX(0...n)，LINK(0...n)，IPServ-data(0...n)和TX(0...n)线程的线程函数指针都放在一个PLTQ中。处理器的第x个核从PLTQ中获取线程函数指针并执行线程，执行完线程后，将线程函数指针放回PLTQ中，整个线程调度就是循环进行取线程、执行线程和放回线程。
通常情况下，每条流水线配置一个缓存队列，用于保存待处理的协议报文。缓存队列可以是FIFO。
在软转发技术领域内，CPU的核的数量一般是流水线条数的2～3倍，在这种情况下会取得较好的转发效率。在本文以下描述中，core的个数为流水线条数的2倍。多核CPU通常有双核、4核、8核，16核，32核，48核和64核等。
预先配置的核的数量不少于流水线的数量，对于n条流水线，预先配置至少n个核，用于执行被启动的协议处理线程，以处理协议报文，例如，预先配置的第x个核执行协议处理线程，以处理缓存队列中的协议报文。执行LINK线程的核与第x个核可以相同，也可以不同。
本发明实施例另行存储协议报文，采用IPserv-protocol线程处理协议报文，而且执行协议处理线程的时长基于缓存队列的当前深度确定，分配更多的核资源来处理协议报文，确保协议报文得到及时处理。每个核的资源，即核的执行时间。
启动的协议处理线程可以放在一个线程组中，预先配置的核从线程组中获取线程函数指针并执行线程，执行完线程后，将线程函数指针放回线程组中。
每个预先配置的核可以与一个协议处理线程绑定，当协议处理线程启动后，绑定的核执行该被启动的协议处理线程。
作为一个可选的实施方式，预先配置的核在执行周期的指定时长内执行被启动的协议处理线程，指定时长根据缓存队列的当前深度所对应的深度级别预先设定，深度级别是对缓存队列的深度范围分级得到的。
在核的每个执行周期中，核可以执行多个线程，完成多次线程的切换。从执行时间上每个执行周期被分为两个部分：分别用于执行PLTQ线程和IPserv-protocol线程。
在预先配置的核中，IPserv-protocol线程和PLTQ线程交替执行，通常是执行一个IPserv-protocol线程，再执行一次PLTQ线程，然后依次执行。在一次交替执行两个线程内，执行IPserv-protocol线程的时长与执行PLTQ线程的时长的比例可以预先配置，从而确保IPserv-protocol线程有稳定的运行周期，保证快速响应。
特殊情况1：如果FIFO中没有协议报文，IPserv-protocol线程会直接退出，将时长释放给PLTQ线程。
特殊情况2：如果FIFO中协议报文超过IPserv-protocol线程的处理能力，同时无法为FIFO分配执行时长更长的IPserv-protocol线程时，将会延长IPserv-protocol线程的执行时长，直到处理完FIFO中的所有协议报文，才退出。
通过配置每个线程的时长比例，就可以控制IPserv-protocol线程占用的核资源。
优选的，多核处理器的所有核均为预先配置的核，每个预先配置的核与一个协议处理线程绑定。
指定时长在执行周期中的初始占比随着深度级别的递增而增加，初始占比均小于100％并保存在线程分配表中，线程分配表还包括核与绑定的协议处理线程的关联信息以及协议处理线程的启动信息。
下面以8个核和4条流水线为例说明本发明实施例的原理。8个核为core0，core1，……，core7，协议处理线程的个数最多为CPU的core数。
图3是本发明实施例多核处理器的线程执行示意图，可以在现有常规软件平台下，增加协议处理流程。图4是图3中协议报文的线程执行示意图。
具体的，数据报文经过一条流水线中的4个线程，4条流水线共16个线程存放在PLTQ线程队列中。PLTQ中的线程包括RX0、LINK0、IPserv-data0、TX0、RX1、LINK1、IPserv-data 1、TX1、RX2、LINK2、IPserv-data 2、TX2、RX3、LINK3、IPserv-data 3和TX3。
4条流水线分别配置有FIFO0、FIFO1、FIFO2和FIFO3缓存队列。
用于处理协议报文的IPserv-protocol线程包括IPserv-protocol0、IPserv-protocol1、IPserv-protocol2、IPserv-protocol3、IPserv-protocol4、IPserv-protocol5、IPserv-protocol6和IPserv-protocol7共8个线程，分别对应core0，core1，……，core7。
协议报文的流向是从LINK0，LINK1，LINK2和LINK3流向协议处理线程，经协议处理线程处理完后，再流向TX0，TX1，TX2和TX3。
在一个示例中，多核处理器的每个核与一个协议处理线程绑定，例如，core0绑定IPserv-protocol0线程，core1绑定IPserv-protocol1线程，以此类推。core2可以执行PLTQ的16个线程中的任意一个线程，但只能执行core2所绑定的IPserv-protocol2，其它核同理。
在核中，IPserv-protocol线程和PLTQ线程交替执行。核在执行周期的指定时长内执行被启动的协议处理线程，在其他时长内执行PLTQ线程。
指定时长可以在初始化时设定，图5是每个核在执行周期内的时长分配示意图，每个执行周期分为多个时间片，其中一个方格代表每个执行周期中的一个时间片，指定时长包括至少一个时间片，从图5中可以看出IPserv-protocol线程在执行周期所占用的Core的时间片，都不相同，由低到高，逐渐增加，呈一定比例，在实际应用中通过调试确定，例如10％-90％，从而形成协议报文的处理能力呈阶梯上升的线程组。
在图5中，每个core中分配给IPserv-protocol线程和PLTQ线程的执行时长是固定的，用于保证线程按时被调度，线程快速响应。每个core中IPserv-protocol线程的指定时长，只有在LINK线程入队FIFO协议报文后，由LINK线程进行激活，在激活的情况下，才用来执行IPserv-protocol线程，来处理协议报文；没有激活的情况下，只执行PLTQ线程，core的全部时间用来处理数据报文。
每个core中分配给IPserv-protocol线程的指定时长只限制IPserv-protocol线程在执行周期内的最大时长，如果协议报文处理完，IPserv-protocol线程提前退出，则实际执行IPserv-protocol线程的时长短于指定时长。
每个core中分配给IPserv-protocol线程的指定时长，存在一个特殊情况是：IPserv-protocol线程短时间地独占整个core所有时长和资源，其触发条件是当前FIFO的平均深度大于IPserv-protocol线程处理能力，且FIFO也分配不到更高处理能力的IPserv-protocol线程时，就会开启短时独占整个core的资源，用于执行IPserv-protocol线程处理协议报文。当FIFO中的协议报文被处理完后，就会退出此模式，可参考图7的流程。
指定时长在执行周期中的占比保存在线程分配表(参见表一)的IPServ-protocol线程的时长占比中。参见表一所示，线程分配表是一个全局表，所有LINK线程都可以访问并更新。
线程分配表保存线程是否被分配、FIFO的深度级别、IPServ-protocol线程ID、IPserv-protocol线程的时长占比和线程绑定Core ID的映射关系。
表一：线程分配表
FIFO深度级别为0～23，可以分为9个区段，前8个区段对应IPserv-protocol0...7，实现协议报文量与对应处理能力的IPserv-protocol线程进行匹配。第9个区段，已超出了所有IPserv-protocol的处理能力，在此区段中默认会启用core独占功能，core有执行时间，在短期内完全用于处理协议报文。
FIFO中的协议报文量越多，就需要执行时间更长(即IPserv-protocol线程的时长占比更大)的IPserv-protocol线程来处理。
在初始化时，可以为各缓存队列指定一个IPserv-protocol线程的时长占比处于中位数的IPserv-protocol线程，如图3中的FIFO0-3，分别对应于IPserv-protocol2-5(IPserv-protocol2-5的时长占比处在中位数)来处理协议报文，后续再根据FIFO的实时平均深度进行动态调整，选择对应的IPserv-protocol线程。
在表一的基础上，线程分配表中还可以保存根据各FIFO启动的IPserv-protocol线程ID信息。
通过配置协议处理线程所绑定的Core执行IPserv-protocol线程的时长占比后，就能提高协议报文占用core的时间比例，保证协议报文的Core资源，并根据情况切换对应时长占比的IPserv-protocol线程。
当IPserv-protocol线程的执行时长不能满足FIFO的需求，又不能分配到更多执行时长的IPserv-protocol线程时，会启动core独占功能，core完全用于执行IPserv-protocol线程，处理协议报文，不执行PLTQ线程。
进一步的，根据缓存队列的当前深度计算实时平均深度，在线程分配表中按照判定条件选择并启动一个未被启动的协议处理线程。
判定条件包括：
1)协议处理线程对应的深度级别匹配实时平均深度；
2)协议处理线程对应的深度级别高于实时平均深度；
3)将缓存队列上次启动的协议处理线程的初始占比更改为100％。
优选的，按照以上1)至3)的顺序，选择并启动一个未被启动的协议处理线程。
参见图6所示，在一个示例中，步骤S120具体包括：
S 121LINK线程将协议报文入队到LINK线程对应的FIFO。
S122根据FIFO的当前深度计算实时平均深度。
计算一段时间内的平均值，FIFO的实时平均深度表示一段时间内FIFO深度的平均值，通常是10ms内，它反应FIFO中的协议报文量。如果使用FIFO的即时深度，因为其波动较大，会引起后续线程频繁切换。
S123在线程分配表中查找与实时平均深度匹配的深度级别对应的IPserv-protocol线程ID(记录为Match-ID)，以及FIFO上次启动的IPserv-protocol线程ID(记录为Current-ID)。Current-ID未被分配。
S124比较Match-ID的时长占比和Current-ID的时长占比，当前者长于后者时，进入步骤S125；当前者短于后者时，进入步骤S128；当二者相等时，进入步骤S1210。
S125判断Match-ID是否被启动，若是，进入步骤S126；若否，进入步骤S127。
S126设置此FIFO对应Current-ID，独占与Current-ID绑定的core的执行周期，进入步骤S1211。
S127将Match-ID分配给此FIFO，并更新线程分配表，进入步骤S1211。
S128判断Match-ID是否被启动，若是，进入步骤S1210；若否，进入步骤S129。
S129将Match-ID分配给此FIFO，并更新线程分配表，进入步骤S1211。
S1210设置此FIFO对应Current-ID，进入步骤S1211。
S1211 LINK线程激活为FIFO分配的IPserv-protocol线程，结束。
具体的，在软件初始化时，根据调试结果确认一个Core执行线程的时间片比例配置，即配置IPserv-protocol线程和PLTQ线程的core时间片的比例。
每个Core依次执行IPserv-protocol线程和PLTQ线程。其中，每个core绑定的IPserv-protocol线程只有一个，可以执行多个PLTQ线程，例如，RX、LINK、IPServ-data和TX线程。
如果FIFO中没有协议报文，对应的IPserv-protocol线程没有激活，Core轮询时只执行PLTQ选定的线程。可能有如下的线程执行顺序：RX2、TX3、IPServ-data2...。
作为一个可选的实施方式，执行协议处理线程的时长根据缓存队列的当前深度动态调整，例如，可以根据缓存队列的当前深度动态调整指定时长。
图7是处理器核中线程执行流程图。
S210 IPserv-protocol线程是否激活，若是，进入步骤S220；若否，进入步骤S270。
S220获取并执行IPserv-protocol线程。
S230判断FIFO是否为空，若否，进入步骤S240；若是，进入步骤S270。
S240从FIFO中读取协议报文并处理。
S250判断是否开启短时独占core的执行周期，若是，返回步骤S230；若否，进入步骤S260。
S260判断指定时长是否用完，若是，进入步骤S270；若否，返回步骤S230。
S270从PLTQ中获取并执行线程。
S280到达执行时长时，返回步骤S210。
以Core7举例，Core7从图2的PLTQ的OUT端口，读取一个线程，从PLTQ读取的线程可能为存储在PLTQ中的16个线程中的任何一个，假定为RX0。
Core7执行线程RX0一段时间，执行时间片配置参见图5。
Core7将执行完的线程RX0，从IN端口放到PLTQ。
Core7执行IPserv-protocol7一段时间，执行时间配置参见图5。
从PLTQ读取新的线程，重复上述步骤。
可能有如下的线程执行顺序：IPserv-protocol7，RX2，IPserv-protocol7，TX3，IPserv-protocol7，IPserv2...等。
还是以流水线条数为4，CPU的Core数为8为例，结合图2、图6和图7，处理器的报文处理过程包括：
1)初始化4个FIFO缓存。
2)初始化8个IPserv-protocol线程。
3)初始化配置每个Core的IPserv-protocol线程的指定时长在执行周期中的初始占比，从Core0到7，初始占比依次从10％，等距增加到90％，初始占比可根据实际情况调整。
4)为4个FIFO指定默认的协议处理线程IPserv-protocol X，如表一，其中x分别为2，3，4和5。
5)以LINKn为例，0≤n≤3，core执行LINKn线程接收到协议报文，入FIFOn。
6)计算一段时间内的FIFO平均深度。
7)根据FIFO平均深度，在全局的线程分配表中，查到对应执行时间的IPServ-protocolX和core id(coreX)。
8)如果当前FIFO默认分配的线程不是IPServ-protocol X，就要启动线程切换流程。
9)访问全局的线程分配表，检查IPServ-protocol X是否被分配。
10)如果IPServ-protocol X没有被分配，就分配给此FIFO，更新全局的线程分配表。
11)如果IPServ-protocol X已被分配了。此时FIFO想切换执行时间更长的协议处理线程，但无法分配，就放弃线程切换，通过启动core短时独占功能，来提高协议处理线程的处理能力。
12)如果IPServ-protocol X已被分配了。此时FIFO想切换执行时间更短的协议处理线程，但无法分配，就放弃切换。
13)Linkn线程向IPServ-protocol X所在的core发出激活消息，激活协议处理线程IPServ-protocol X。
14)执行IPserv-protocol X线程处理协议报文。
15)Core首先判断IPserv-protocol X是否激活，如果没有激活，就获取PLTQ的线程并执行，执行过程中，PLTQ线程会进行时间片检查，PLTQ配置的时间片用完就会退出，并重复此步骤。
16)如果IPserv-protocol X已激活，就执行IPserv-protocol X线程，检FIFO中是否有报文，如果没有就退出协议处理线程。如果有协议报文，就从FIFO中读取数个协议报文，处理完已取得的协议报文后，就进行时间片检查，时间片没有用完，就重复从FIFO中读取协议报文和处理。时间片用完(如果启用了短时core独占，就不会进行时间片检，线程只有在FIFO为空时才会退出)，或FIFO深度为空，就退出协议处理线程。
17)处理完的协议报文由IPserv-protocolX传递给TXn线程，从硬件发送出去。
本发明实施例具有以下特点：
1)在轻载业务下，多个协议报文的缓存队列都分配到执行时间短的IPserv-protocol线程，其它协议处理线程处于未分配状态，不会被激活，处于备用(Standby)，Core占用率低，节省CPU资源。
2)在重载业务下，可以分配到执行时间更长的IPserv-protocol线程，使协议报文的处理能力增强，维持协议面的稳定。
3)在多条流水线协议报文散列不均匀的情况下，会根据每条流水线的FIFO中的协议报文量，自动分配协议处理线程IPserv-protocol，自动适应不同负载。
4)允许IPserv-protocol线程独占core资源，可应对协议报文突发，防止掉包。
参见图8所示，本发明实施例还提供一种协议报文的处理系统，设于多核处理器中，涉及基于多核处理器的产品包括：a)路由器/接入路由器；b)业务板卡；c)虚拟化宽带远程接入服务器(Virtual Broadband Remote Access Server，VBRAS)；d)虚拟防火墙。
协议报文的处理系统包括缓存队列、数据报文处理模块和协议报文处理模块。
每个缓存队列配置给一条流水线。
数据报文处理模块设于每个核中，用于从流水线线程队列获取任一条流水线的链路解析线程，执行链路解析线程得到待处理的三层报文；当待处理的三层报文为协议报文时，将协议报文存入为该条流水线配置的缓存队列，并启动一个协议处理线程。
协议报文处理模块设于预先配置的核中，预先配置的核的数量不少于流水线的数量，协议报文处理模块用于执行被启动的协议处理线程，以处理协议报文，其中，执行协议处理线程的时长是根据缓存队列的当前深度确定的。
作为一个可选的实施方式，协议报文处理模块用于在执行周期的指定时长内执行被启动的协议处理线程，指定时长根据缓存队列的当前深度所对应的深度级别预先设定，深度级别是对缓存队列的深度范围分级得到的。
优选的，多核处理器的所有核均为预先配置的核，每个协议报文处理模块与一个协议处理线程绑定。
指定时长在执行周期中的初始占比随着深度级别的递增而增加，初始占比均小于100％并保存在线程分配表中，线程分配表还包括核与绑定的协议处理线程的关联信息以及协议处理线程的启动信息。
进一步的，协议报文处理模块用于根据缓存队列的当前深度计算实时平均深度，在线程分配表中按照判定条件选择并启动一个未被启动的协议处理线程。
判定条件包括：
协议处理线程对应的深度级别匹配实时平均深度；
协议处理线程对应的深度级别高于实时平均深度；
将缓存队列上次启动的协议处理线程的初始占比更改为100％。
进一步的，执行协议处理线程的时长根据缓存队列的当前深度动态调整。
进一步的，协议处理线程执行后，将被更改为100％的时长占比恢复为初始占比。
本发明不局限于上述实施方式，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围之内。本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。
Claims (10)
1.一种协议报文的处理方法，其特征在于，其包括：
多核处理器的核从流水线线程队列获取任一条流水线的链路解析线程，执行链路解析线程得到待处理的三层报文；
当待处理的三层报文为协议报文时，将协议报文存入为该条流水线配置的缓存队列，并启动一个协议处理线程；
一个预先配置的核执行被启动的协议处理线程，以处理协议报文，其中，预先配置的核的数量不少于流水线的数量，执行协议处理线程的时长是根据缓存队列的当前深度确定的。
2.如权利要求1所述的协议报文的处理方法，其特征在于：
所述预先配置的核在执行周期的指定时长内执行被启动的所述协议处理线程，指定时长根据所述缓存队列的当前深度所对应的深度级别预先设定，深度级别是对所述缓存队列的深度范围分级得到的。
3.如权利要求2所述的协议报文的处理方法，其特征在于：
多核处理器的所有核均为所述预先配置的核，每个所述预先配置的核与一个所述协议处理线程绑定；
所述指定时长在所述执行周期中的初始占比随着所述深度级别的递增而增加，初始占比均小于100％并保存在线程分配表中，线程分配表还包括核与绑定的所述协议处理线程的关联信息以及所述协议处理线程的启动信息。
4.如权利要求3所述的协议报文的处理方法，其特征在于：
根据所述缓存队列的当前深度计算实时平均深度，在所述线程分配表中按照判定条件选择并启动一个未被启动的所述协议处理线程；
所述判定条件包括：
所述协议处理线程对应的所述深度级别匹配实时平均深度；
所述协议处理线程对应的所述深度级别高于实时平均深度；
将所述缓存队列上次启动的所述协议处理线程的所述初始占比更改为100％。
5.如权利要求1所述的协议报文的处理方法，其特征在于：
所述执行协议处理线程的时长根据所述缓存队列的当前深度动态调整。
6.一种协议报文的处理系统，设于多核处理器中，其特征在于，所述系统包括：
至少一个缓存队列，每个缓存队列配置给一条流水线；
数据报文处理模块，其设于每个核中，用于从流水线线程队列获取任一条流水线的链路解析线程，执行链路解析线程得到待处理的三层报文；当待处理的三层报文为协议报文时，将协议报文存入为该条流水线配置的缓存队列，并启动一个协议处理线程；
协议报文处理模块，其设于预先配置的核中，预先配置的核的数量不少于流水线的数量，协议报文处理模块用于执行被启动的协议处理线程，以处理协议报文，其中，执行协议处理线程的时长是根据缓存队列的当前深度确定的。
7.如权利要求6所述的协议报文的处理系统，其特征在于：
所述协议报文处理模块用于在执行周期的指定时长内执行被启动的所述协议处理线程，指定时长根据所述缓存队列的当前深度所对应的深度级别预先设定，深度级别是对所述缓存队列的深度范围分级得到的。
8.如权利要求7所述的协议报文的处理系统，其特征在于：
多核处理器的所有核均为所述预先配置的核，每个所述协议报文处理模块与一个所述协议处理线程绑定；
所述指定时长在所述执行周期中的初始占比随着所述深度级别的递增而增加，初始占比均小于100％并保存在线程分配表中，线程分配表还包括核与绑定的所述协议处理线程的关联信息以及所述协议处理线程的启动信息。
9.如权利要求8所述的协议报文的处理系统，其特征在于：
所述协议报文处理模块用于根据所述缓存队列的当前深度计算实时平均深度，在所述线程分配表中按照判定条件选择并启动一个未被启动的所述协议处理线程；
所述判定条件包括：
所述协议处理线程对应的所述深度级别匹配实时平均深度；
所述协议处理线程对应的所述深度级别高于实时平均深度；
将所述缓存队列上次启动的所述协议处理线程的所述初始占比更改为100％。
10.如权利要求6所述的协议报文的处理系统，其特征在于：
所述执行协议处理线程的时长根据所述缓存队列的当前深度动态调整。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010153040.5A CN113364705B (zh) | 2020-03-06 | 2020-03-06 | 一种协议报文的处理方法及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010153040.5A CN113364705B (zh) | 2020-03-06 | 2020-03-06 | 一种协议报文的处理方法及系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113364705A CN113364705A (zh) | 2021-09-07 |
| CN113364705B true CN113364705B (zh) | 2022-06-17 |
Family
ID=77524195
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010153040.5A Active CN113364705B (zh) | 2020-03-06 | 2020-03-06 | 一种协议报文的处理方法及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113364705B (zh) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1545216A (zh) * | 2003-11-20 | 2004-11-10 | 中兴通讯股份有限公司 | 网络处理器中核心处理器与微引擎之间的通信方法 |
| CN1883146A (zh) * | 2003-12-23 | 2006-12-20 | 思科技术公司 | 在路由选取协议的实现中分布路由选择的系统和方法 |
| CN101217520A (zh) * | 2007-12-29 | 2008-07-09 | 华为技术有限公司 | 无线分组域网关性能自适应的方法及装置 |
| CN102299846A (zh) * | 2011-08-19 | 2011-12-28 | 杭州华三通信技术有限公司 | 一种bfd报文传输方法和设备 |
| CN107426113A (zh) * | 2017-09-13 | 2017-12-01 | 迈普通信技术股份有限公司 | 报文接收方法及网络设备 |
| CN108881033A (zh) * | 2018-06-20 | 2018-11-23 | 湖南戎腾网络科技有限公司 | 基于fpga+npu的面向lte网络的高速用户溯源方法 |
| US10412018B1 (en) * | 2017-03-21 | 2019-09-10 | Barefoot Networks, Inc. | Hierarchical queue scheduler |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8015392B2 (en) * | 2004-09-29 | 2011-09-06 | Intel Corporation | Updating instructions to free core in multi-core processor with core sequence table indicating linking of thread sequences for processing queued packets |
-
2020
- 2020-03-06 CN CN202010153040.5A patent/CN113364705B/zh active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1545216A (zh) * | 2003-11-20 | 2004-11-10 | 中兴通讯股份有限公司 | 网络处理器中核心处理器与微引擎之间的通信方法 |
| CN1883146A (zh) * | 2003-12-23 | 2006-12-20 | 思科技术公司 | 在路由选取协议的实现中分布路由选择的系统和方法 |
| CN101217520A (zh) * | 2007-12-29 | 2008-07-09 | 华为技术有限公司 | 无线分组域网关性能自适应的方法及装置 |
| CN102299846A (zh) * | 2011-08-19 | 2011-12-28 | 杭州华三通信技术有限公司 | 一种bfd报文传输方法和设备 |
| US10412018B1 (en) * | 2017-03-21 | 2019-09-10 | Barefoot Networks, Inc. | Hierarchical queue scheduler |
| CN107426113A (zh) * | 2017-09-13 | 2017-12-01 | 迈普通信技术股份有限公司 | 报文接收方法及网络设备 |
| CN108881033A (zh) * | 2018-06-20 | 2018-11-23 | 湖南戎腾网络科技有限公司 | 基于fpga+npu的面向lte网络的高速用户溯源方法 |
Non-Patent Citations (3)
| Title |
|---|
| QoS and MPLS design issues in NoCs;E.N.Lallas et al.;《SEEDA-CECNSM》;20180924;全文 * |
| 基于多核处理器的网络安全协议并行处理研究;刘磊等;《信息网络安全》;20110910;全文 * |
| 基于无锁队列算法的报文分发流水线模型;白正等;《网络安全技术与应用》;20130215;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113364705A (zh) | 2021-09-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5905921B2 (ja) | トラフィック及び負荷を認識する動的なキュー管理 | |
| US8571048B2 (en) | Dynamic memory queue depth algorithm | |
| US9509615B2 (en) | Managing link aggregation traffic in a virtual environment | |
| CN113285892A (zh) | 报文处理系统、方法、机器可读存储介质以及程序产品 | |
| US7701849B1 (en) | Flow-based queuing of network traffic | |
| CN112714023B (zh) | 一种tsn带宽预留系统、带宽预留值计算方法及装置 | |
| KR101720259B1 (ko) | 중앙 제어기에 의해 제어되는 데이터 패킷들을 수신 및 저장하는 장치 및 방법 | |
| US9350666B2 (en) | Managing link aggregation traffic in a virtual environment | |
| US9686178B2 (en) | Configuring link aggregation groups to perform load balancing in a virtual environment | |
| KR100645537B1 (ko) | 안정적인 패킷 포워딩을 위한 동적인 큐 관리방법 및 이를위한 네트워크 프로세서의 구성요소 | |
| WO2014115207A1 (ja) | バスインタフェース装置、中継装置、およびそれらを備えたバスシステム | |
| JP7487316B2 (ja) | サービスレベル構成方法および装置 | |
| Meixner et al. | A new global router based on a flow model and linear assignment | |
| Cheng et al. | Application-aware SDN routing for big data networking | |
| US20060251071A1 (en) | Apparatus and method for IP packet processing using network processor | |
| CN113364705B (zh) | 一种协议报文的处理方法及系统 | |
| CN109547352B (zh) | 报文缓存队列的动态分配方法和装置 | |
| Hwang et al. | Load balancing and routing mechanism based on software defined network in data centers | |
| WO2009093299A1 (ja) | パケット処理装置およびパケット処理プログラム | |
| US9548885B2 (en) | Systems and methods for providing replicated data from memories to processing clients | |
| WO2022127895A1 (zh) | 一种报文处理方法及相关设备 | |
| Bays et al. | Flow based load balancing: Optimizing web servers resource utilization | |
| CN116954874A (zh) | 资源分配方法、装置、设备及存储介质 | |
| US11271897B2 (en) | Electronic apparatus for providing fast packet forwarding with reference to additional network address translation table | |
| JP5817458B2 (ja) | 転送処理装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20221121 Address after: No. 6, West Hupan Road, Xinglong Street, Tianfu New District, Chengdu, Sichuan 610213 Patentee after: Chengdu Fenghuo cloud Information Technology Co.,Ltd. Address before: 430000 No. 6, High-tech Fourth Road, Donghu High-tech Development Zone, Wuhan City, Hubei Province Patentee before: FIBERHOME TELECOMMUNICATION TECHNOLOGIES Co.,Ltd. Patentee before: Chengdu Fenghuo cloud Information Technology Co.,Ltd. |
|
| TR01 | Transfer of patent right |