http://blog.cnxgo.com/blog/index.php zh-cn http://blog.cnxgo.com/blog/read.php?29 cnxgo <admin@cnxgo.com> Fri, 14 May 2010 07:35:15 +0000 http://blog.cnxgo.com/blog/read.php?29 http://blog.cnxgo.com/blog/read.php?28 cnxgo <admin@cnxgo.com> Fri, 14 May 2010 07:12:50 +0000 http://blog.cnxgo.com/blog/read.php?28 VIDL            95%               6/a6a367bb  空闲任务，这个任务占用率越高，CPU越空闲。
TICK             0%               0/ 4626774  定时器相关
co0             0%               0/  1fd656  串口服务
IPCR             0%               0/  82bc1b  内部通讯相关
VPR             0%               0/  d2e9a7  内部通讯相关
VPS             0%               0/  14f5ff  内部通讯相关
Ecm             0%               0/  c33122  内部通讯相关  
RTMR             0%               0/ 431e350  定时器相关
IPCQ             0%               0/  4b71db  内部通讯相关
  VP             0%               0/    237f  内部通讯相关
RPCQ             0%               0/  13b4ad  内部通讯相关
BEAT             0%               0/  2a6146  系统监控相关  
VMON             0%               0/   760e8  系统监控相关
VRRP             0%               0/  5dc925  VRRP相关  
INFO             0%               0/ 44deab1  信息中心
LCS             0%               0/  980a4b  license
CDEV             0%               0/  385a40  设备管理相关
DFSU             0%               0/ 1beefd5  灵活插卡
DSMS             0%               0/   36fa0  内部通讯相关
PPI             0%               0/  130bd0  二层接口相关
L2IF             0%               0/ 34fdf6c  二层接口相关
MFLP             0%               0/   5c02b  不用关心
LLDP             0%               0/   55fba  LLDP协议相关
APS             0%               0/  2e6748  系统相关  
FIB6             0%               0/  f64346  IPV6相关
BFD             0%               0/  744819  BFD协议
ROUT             0%               0/ d01a028  路由相关
OAM             0%               0/  63dd7a  OAM
LSPA             0%               0/  7b21e9  MPLS协议
PHY             0%               0/   51284  系统相关
RSVP             0%               0/  5e7018  系统相关
CSPF             0%               0/ 18d0e22  系统相关
TNLM             0%               0/  313ebc  系统相关
SNPG             0%               0/  7f6c2d  igmp snooping
EOAM             0%               0/   59670  以太链路检测
TRAF             0%               0/  6524e3  系统相关
DLDP             0%               0/   51f5d  DLDP协议
LDT             0%               0/   43bb7  LDT协议
ELAB             0%               0/   7a9a3  电子标签
GREP             0%               0/   3e469  GRE
SECE             0%               0/  2db26f  安全
QOSA             0%               0/    4041  QOS
IPMC             0%               0/  36d642  组播协议
SOCK             0%               0/  9095d5  通讯相关
VTYD             0%               0/  619a17  telnet服务
TUNN             0%               0/  77f664  TUNNEL
TRAP             0%               0/ 223ff4e  信息中心相关
MDMT             0%               0/ 15fae4b  modem
LOAD             0%               0/   486f1  系统相关
NTPT             0%               0/ b553133  NTP时间同步
TAC             0%               0/  613d31  Tacacs
UCM             0%               0/    c663  不用关心
LAM             0%               0/    314c  不用关心
HS2M             0%               0/  488ca7  系统相关
MSTP             0%               0/ 276034e  MSTP协议
SMLK             0%               0/   74311  smartlink协议
RRPP             0%               0/   a6156  RRPP
DHCP             0%               0/  160760  DHCP
RMON             0%               0/   a99ea  流量监控
HOT             0%               0/ 3833372  系统相关
vt0             0%               0/  1d4592  telnet服务
  OS             5%               0/       0  操作系统任务
]]> http://blog.cnxgo.com/blog/read.php?24 cnxgo <admin@cnxgo.com> Thu, 02 Jul 2009 03:22:54 +0000 http://blog.cnxgo.com/blog/read.php?24 http://blog.cnxgo.com/blog/read.php?11 cnxgo <admin@cnxgo.com> Mon, 21 Jul 2008 02:06:22 +0000 http://blog.cnxgo.com/blog/read.php?11

在当前的三层以太网交换设备中，报文的二层交换和三层路由主要由交换芯片和网络处理器完成，CPU基本上不参与交换和路由过程，主要完成管理和控制交换芯片的功能[1]。

在这种情况下，CPU的负载主要来自以下几个方面：协议的定时驱动、用户的配置驱动、外部事件的驱动。其中，外部事件的驱动最为随机，无法预料。典型的外部事件包括端口的连接/断开(Up/Down)，媒体访问控制(MAC)地址消息的上报(包括学习、老化、迁移等)，CPU通过直接存储器存取(DMA)收到包，CPU通过DMA发包等。

在以上所列的外部事件中，又以CPU通过DMA收到包之后的处理最为复杂。因为数据包由低层上送到上层软件时，各协议的处理动作千差万别，可能会涉及到发包、端口操作、批量的表操作等。所以，只有处理好CPU的收发包的相关问题，才能使相关的上层协议正常交互，从而使交换机稳定、高效地运行。

1 可能涉及到的问题

以下就CPU收发包可能涉及的各个方面分别说明。

下面的分析都基于典型的CPU收发包机制：CPU端口分队列，通过DMA接收，采用环形队列等。

1.1 CPU的负载与收包节奏控制

根据交换机处理数据包的能力，决定单位时间上送到CPU的包的个数；决定了单位时间上送多少个包给CPU后，再考虑上送数据包的节奏。

假设通过评估，确定了单位时间上送CPU数据包的上限，例如每秒x个数据包。



图1

图1给出了两种典型的处理手段：匀速上报CPU、突发(Burst)方式上报CPU，下面分别分析一下这两种方式的优劣：

(1)匀速上报CPU

数据包匀速上报CPU时，对CPU队列的冲击较小，而且对CPU队列的缓冲能力要求不高，CPU队列不必做得很大。
(2)突发(Burst)方式上报CPU

交换芯片(采用ASIC)一侧的硬件接收队列和DMA内存空间中的环形队列，一起赋予了交换机一定的缓冲能力(针对上送CPU的数据包)。利用这个缓冲能力，我们可以把控制周期适当放长，并设定控制的粒度(单位控制周期内CPU收报个数的上限)，采用类似于电路中负反馈的机制动态地使能和关闭CPU收包功能。这样就在宏观上实现了对数据包上送CPU速率的控制。另外，如果交换芯片(采用ASIC)支持基于令牌桶算法的CPU端口出方向流量监管或整形功能[2-3]，且监管或整形的最小阈值可以满足CPU限速的需要，则可以利用这个功能控制数据包上送CPU的节奏，减小CPU的负载。这样软件的处理就简化了很多。

1.2 CPU端口队列的长度规划

如果仅考虑交换机CPU端口的缓冲能力，CPU端口队列当然是越长越好，但是必须兼顾对其他功能以及性能的影响。针对不同的ASIC芯片，需要具体问题具体分析。

1.3 零拷贝

零拷贝是指在整个数据包的处理过程中，使用指针做参数，不进行整个数据包的拷贝。这样可以大大提高CPU的处理效率。

使用零拷贝后，会一定程度上降低软件处理的灵活性，我们会面临到这样的问题：如果协议栈需要更改一个数据包的内容，会直接在接收缓存(buffer)上修改，但是如果需要在数据包中删除或添加字段(例如添加或删除一层标签(tag))，即数据包的长度需要变化时，应该如何处理。

添加或删除字段，必然会导致数据包头一侧或包尾一侧的位置发生移动，如果包尾一侧移动，问题比较简单，只要数据包总长度不超过buffer边界即可。由于通常此类操作都靠近包头的位置，如果包头一侧移动，效率会比较高，所以协议栈在处理时可能更倾向于在包头一侧移动，这时就需要驱动在分配buffer时做一些处理：

(1)接收数据包时，头指针不能指向buffer边界，需要向后偏移一定裕量，同时单个buffer的大小也必须兼顾到最大传送单元(MTU)和该裕量。

(2)释放数据包时buffer首指针需要作归一化处理(如图2所示)。


图2

1.4 中断/轮询

目前交换机涉及到的外部中断主要由交换芯片产生，交换芯片主要的外部中断包括DMA操作(如收到包、发包结束、新地址消息等等)和一些出错消息。如果中断请求过于频繁，中断服务程序(ISR)和其他进程之间频繁地上下文切换会消耗大量CPU时间。如果有持续大量的中断请求，CPU会始终处于繁忙状态，各种协议得不到足够的调度时间，从而导致协议状态机超时等严重故障。

为了避免事件触发频率不可控的问题，可以使用轮询机制，通常的做法是用CPU定时器触发原先由外部中断触发的ISR，由于定时器触发的间隔是固定的，所以ISR执行的频率得到了控制，避免了上述的问题。

轮询和外部中断相比，只是节奏可控(外部中断的节奏取决于外部事件发生的频率，CPU不可控)。但是，轮询也有其不可避免的缺点——响应慢。不能满足某些实时性要求较高的功能。另外，人们会发现用ping命令检测交换机3层接口大包时，使用轮询方式的交换机比使用中断方式的交换机的时延明显要大。
如果能通过某种机制，避免持续、大量的中断请求，则既可以保证CPU不会过于繁忙，又保留了中断实时处理的优点。

典型的会产生大量中断事件的行为是CPU接收数据包和MAC地址消息上报。以收包为例，在前面“CPU负载与收包节奏控制”部分提到的Burst方式就是根据实时的流量，控制接收DMA的开关，这样就达到了使中断源受控的目的，这种类似负反馈的机制可以很好的避免持续的中断事件上报CPU。

总之，轮询控制简单，但实时性较差；中断实时性好，但是使所有的中断源受控有一定难度。在系统初始设计阶段，我们需要综合考虑需求以及芯片对外部事件的处理方式，来决定采用中断或者轮询方式，或者两者兼用。

1.5 多进程环境中外部事件的处理机制

常见的外部事件(中断事件)包括收到包、包发送完(这里指的都是CPU收发包)，包括收到MAC地址消息、MAC表操作完成等。

如果把各类中断事件的处理放在一个进程里，就人为地造成了各个事件耦合性增强，增加了各种事件相互制约的机会。

在多任务操作系统中，为了能更灵活地处理各个事件，减少事件之间的子相互制约关系，各种事件应当尽可能地单独起进程，或者根据处理方式的不同划分为几个进程，至少用单个进程来处理是不合适的。

1.6 协议包保护和CPU保护

对于基于ASIC的交换机，协议包保护是指利用ASIC芯片的某些机制，把特定的协议包指定到特定的端口队列上去，保证其经DMA队列上送CPU的优先级；CPU保护是指尽量减少不必要的数据包对CPU的冲击。

实现协议包保护的必要条件：

(1)CPU端口必需支持严格优先级(SP)或者带权重的罗宾环(WRR)的调度算法。

(2)交换芯片必需具有较强的流分类能力，且可以给不同的流指定不同的端口队列。

在系统方案设计时我们需要兼顾对协议报文的保护和对CPU的保护，应该尽量做到：

(1)保证CPU收包通道和发包通道的畅通。

(2)精确匹配，按需选取。充分利用ASIC芯片的访问控制列表(ACL)功能，尽量精确地匹配各类协议报文。必要时需要匹配到4层字段[4]。

实现以上几点时，应兼顾其他功能及整机性能的限制。

1.7 效率降低的避免

在多任务操作系统中，各种事件需要用尽量短的时间片处理完成，以保证其他任务有足够的机会得到调度。所以我们在调用任何函数时都要考虑其执行效率。除了算法本身会影响执行效率之外，频繁地访问某些硬件也相当耗时，而这一点往往容易被忽略。

2 结束语

随着以太网相关技术的发展，交换芯片和网络处理器的处理能力不断被提升；相比之下，数据交换设备中CPU处理性能的提升程度远远不及交换芯片和网络处理器；同时数据交换设备支持的业务种类也在不断增加，对CPU承载的业务量也有了更高的要求。在这种情况下，交换设备容量以及支持业务种类的大幅提升和有限的CPU资源之间的矛盾会日益凸显。因此，做好CPU和交换芯片以及网络处理器接口的缓冲管理、队列调度以及流量监管，合理利用CPU资源，是保证数据交换设备安全、稳定运行的前提，也是目前及将来数据交换设备开发的重要课题。 ]]>