分享

从思科发布的资料可以得知，ASR1000系统的整个软件操作系统叫做IOS-XE。IOS-XE是一个基于Linux的IOS操作系统。如何理解这个“基于Linux的IOS操作系统”呢？笔者会在将来单独对思科的操作系统的演化和战略做专题分析。对于拥有QFP芯片做转发和服务处理的ASR1000系统，IOS-XE的基本特点是：

–在控制平面上，可以支持单卡（RE）的两个IOS的运行。从而可以支持单RE（控制平面）的HA，例如，ISSU。这是非常重要的一个亮点。思科就是利用Linux 2.6之后的KVM虚拟技术，从而在Linux上运行了两个IOS。每个IOS作为一个Linux的用户进程来运行。

–在ESP板子上，或者说，数据处理卡上，通过一个主控CPU（一个PowerPC），运行一个Linux Kernel和相应的Chasis Manager， Forwarding Manager等管理进程，并与RE的IOS和相应的进程通过标准的IPC进行通信，从而达到控制平面和数据平面的各种路由，ACL，Config， Policy，动态log数据采集，错误汇报等同步工作。另外，这个主控CPU起到一个控制QFP芯片的作用。换言之，QFP的所有软件都是这个主控CPU来安装，启动，运行的。QFP在这个层面上，扮演的是一个（专门处理数据报文的）协处理器的角色。

–在线卡（SIP)上，也通过一个主控CPU（一个PowerPC），运行一个Linux Kernel和相应的Chasis Manager， Interface Manager等管理进程，并与RE的IOS和相应的进程通过标准的IPC进行通信，从而达到控制平面和线卡的各种同步工作 。

在这篇文章里，笔者不详细讨论控制平面RE和线卡的软件系统，而是专注于数据处理卡ESP和QFP的软件结构。

ESP和QFP的软件结构图基本上如下图所示：

从上图可知，QFP软件子系统分为三个部分：位于主控CPU上的Linux核心上的QFP Client进程；位于主控CPU上的Linux核心里的QFP Driver（驱动）代码函数库，和位于QFP芯片40个Xtensa核上的QFP代码。QFP上的代码通过HyperTransport Interface与主控CPU上的QFP Client进行通信。通过SPI 4.2来获取报文数据，启动加密引擎，和做HA的处理（与另外的ESP板子上的QFP芯片）。主控CPU上的Linux环境中的Chaisis Manager和Forwarding Manager通过一个1Gbps的以太端口与RE（控制平面）通过IPC进行通信。

对于QFP的160(40 * 4)个线程，其软件结构（环境）大致是这样的：

×QFP上没有一个宿主操作系统。没有Linux kernel，当然更不存在IOS等。QFP上多核部分的数据报文处理逻辑应该是运行在一个裸机环境下。或者一个非常简单的硬件抽象层上（HAL）。这个HAL做一些简单的Tensilica Xtensa ISA的初始化，TLB的设置，中断的处理，内存的划分等等。从目前思科所以公开资料，看不出来其运行了任何OS和微内核。

×QFP的启动， 数据报文处理软件的下载，安装，运行，都是由主控CPU，通过HT接口，来控制的，例如，对于主控CPU而已，QFP的控制寄存器，就是主控CPU下可看见的一批Memory Mapped I/O地址。可以被读，写等。QFP Driver逻辑就是完成QFP驱动的Linux核心模块。

×QFP的线程作为引擎的角色，运行数据报文处理软件。

从上图可见，笔者将QFP的160个线程做了一个功能划分–控制线程和数据线程。

控制线程的功能是在QFP的多核上提供与ESP板子上主控CPU（一个PowerPC的处理器）进行通信，例如，接收来自主控CPU通过HT接口发来的各种控制消息；将QFP的各种状态数据，Log数据等等发回给主控CPU。读者需要注意到的是：FIB表的任何更新路径是：控制平面（RE）通知并发送给ESP的主控CPU。主控CPU通知并发送给QFP的控制线程。控制线程通过IPC将FIB存储在其能访问的内存中，例如RLDRAM。

数据线程的功能就比较直接和单纯。做纯粹的数据报文处理。

基本上，思科是不可能透露其QFP多核上软件结构的细节。但是，笔者认为，其结构应该大致为上述分析的结果。

在控制线程方面，另外一个工程选择可以是通过中断处理例程来实现，从而可以避免将160个线程中的几个单独拿出来做控制用，从而损害数据处理的能力。但是通过中断例程的方法的缺点也是比较明显，例如，对线程的cache缓存的打断和侵入，从而导致数据报文处理的性能受到影响。还有的不确定性在于，QFP的多核的中断处理逻辑的发送机制是如何设计的。是每个Xtensa的核都有一个中断逻辑，还是整个40个核拥有一个中断逻辑。

不同的QFP的微结构设计，都会导致软件系统设计的取舍不一。

另外，笔者感觉QFP上的40个核上的软件逻辑的稳定性和可扩展性非常有可能存在许多潜在的问题。如果没有一个良好的轻量级的微内核的支撑，上述的“run to complete”的死循环（while（1）…)代码结构是有许多问题的。当然，从这个角度，读者应该可以认识到，QFP里提供的硬件锁逻辑（提供许多spinlock，mutex等）是非常重要的。对于性能和编程模型，都是很关键的。

另外，从目前分析的QFP多核的软件结构来看，对于一个QFP的线程处理了崩溃，对其他线程的影响是什么 ？ESP主控CPU如何对待这种异常，是重新启动QFP全部系统，还是做而且只是重新启动那个死掉的线程？从笔者的技术观点，应该是，一旦主控CPU发现异常，HA的Active/Passive就会切换。这个当前的QFP全部重新启动，从主控CPU拿到QFP的代码，并且从新运行。这个也是非常可以理解的，例如ISSU的Upgrade等。

总之，在QFP的多核上构筑一个良好的软件系统是不容易的。目前来看，思科的ASR1000上的QFP软件也是比较简单的。

这里面原因有二：

×报文处理引擎，简单就是美。简单就是高性能。

×非常不容易设计和把握。

分享