交换机的内部 [4]

3 Switch Fabric

交换模块主要有两种实现方式，一种是基于共享内存的方式，一种是基于交换矩阵的方式；共享内存方式的最大优点就是成本较低，而且这种方式也决定了整个交换机是集中式的架构，系统扩展性有限，无法支持很高吞吐量；相比基于交换矩阵方式的交换机主用于中高端的交换机，采用分布式的交换架构，交换模块一般都支持输入模块到输出模块的无阻塞转发，整个系统有很好的扩展性。

3.1 基于共享内存的交换

基于共享内存的交换模块的系统结构如下图所示：

如上图所示，输入模块从free buffer pool中取出frame descr，将frame拷贝到其对应的shared memory中，并将input frame descr放到output queue中，输出模块对output queue 进行调度，从中取出frame descr，从而得到frame在shared memory中的位置，将其拷贝到输出模块内部的fifo，然后完成输出。

基于共享内存的交换结构整体比较简单，frame data在输入模块和输出模块间的转移转变为对frame descr的转移，而实际上只是对free queue和output queue进行的若干指针的操作，操作简单；另外还可以将输入模块的lookup工作和frame data的拷贝工作两者并行进行，这样可以进一步提高系统效率，减小latency。采用共享内存方式还有一个特点就是可以很方便的支持multicast，lookup engine可以在其输出的input vector中添加新的字段标明这个frame需要在那几个output port上输出，从而在将frame descr添加到各个output queue的时候维护frame data buffer的引用计数，只有在引用计数为0时，这个frame descr才重新返回到free pool中，因此可以完全避免为multicast重复拷贝frame data的问题（当然，各个output port从shared memory拷贝frame data到自身的fifo中的操作时不可避免的）。

基于共享内存的交换方式通过共享内存带来很多实现上的便利，但是这也同样在是制约共享内存交换方式性能提高的主要瓶颈所在，即内存带宽的限制。通过上面的介绍，我们知道共享内存方式要完成一个frame的转发至少需要读写内存两次，一次是从输入模块拷贝data到shared memory，一次是从shared memory拷贝data到输出模块，假设我们采用一般的667MHz的DDR内存，32bits的带宽，那么整个内存的带宽是32bits x 667MHz x 2 = 40Gbps, 但是在实际应用的统计中，最高只能利用内存带宽的50% - 70%，假如保守取50%，再去掉每个frame需要读写memory两次，如果交换机的每个端口采用100M全双工的模式，再加两个1G的uplink端口，算下来最多只能支持24个百兆端口。因此只能用于低端市场。

但是随着IC工艺的提高，基于共享内存的交换方式还是有很大的吸引力，对于内存带宽的瓶颈问题，可以采用通过提高时钟频率，采用64bits总线，使用QDR内存等方式进行一定改善；而且随着集成度的提高越来越多将内存集成到芯片内部的形式免除布线的困扰可以很大地提高内存带宽。

3.2 基于交换矩阵的交换

基于交换矩阵的交换方式的系统结构如如下图所示：

从上图可以看出，输入模块和输出模块通过一个fabric交换逻辑连接起来，理想情况下输出端口没有发生冲突时可以整个fabric可以实现所有输入模块同时完成向输出模块的转发，因此可以提供很高的吞吐量。

基于交换矩阵的交换，每个要转发的frame都是经由fabric的转发，发送到output port。由于每个input port只连接到fabric的一个端口，当其有多个frame要转发到不同的output port时，只能等前面frame转发结束才能转发后面的frame；而当有多个input port同时需要向某个output port转发时，就会产生冲突，因此fabric本身内部由arbiter对每个input port的请求进行授权，只有经过授权的input port才可使用其转发路径。

由于会有输出端口冲突的问题，就需要再input port对待转发的frame进行排队，就会出来HOL阻塞的问题。具体如下图所示：

上图中，各个端口都需要将frame转发到output port 9，因此在各个input port都造成后续frame的阻塞，因此很大可能造成其他output port的空闲，降低各个channel的利用率，而且当后续frame的优先级高于前面到output port 9的frame时，也造成了低优先级frame阻塞高优先级frame的问题；总是每当在input queue排队的时候，HOL阻塞问题总是必须要解决的问题之一。

针对HOL阻塞的解决方法有若干种，比如引入queue lookahead，采用priority queue，采用per-output-queue input queue等。

其中最简单的就是引入queue lookahead，这种方法无法完全的解决HOL阻塞，但由于其简单性，其他多种解决方法大多也同时使用了queue lookahead的机制。其具体方法为如下：当多个input port对同一个output port进行争用的时候，fabric arbiter只会对一个input port进行授权，其他input port将不得不进行等待。Queue lookahead就是当其他input port进行等待时，检查队列中的第二个frame对应的output port是否空闲，如果空闲将转发队列中的第二个frame，转发结束后将继续请求队列中第一个frame的output port，如果仍然失败，将继续进行queue lookahead。很明显，这种方法有一定缺陷，当队列中被lookahead的frame与前面的frame为同一个output port的时候，lookahead将不再起作用；但是由于其性价比，这种方法也被广泛利用。

第二种采用priority queue的方式，即在input port提供Hi和lo两个input queue，对于高优先级的frame将放到hi queue中，输入端口对fabric申请授权时首先对hi queue中的frame进行申请，这样虽然不能完全解决HOL的问题，但是起码低优先级的frame无法阻塞高优先级的frame。完成对于priority queue的支持也主要有输入模块的帧分类器来完成，在帧分类器中直接将frame分为hi和low或更多种优先级，直接把frame enqueue到各自的队列中，另外通常这种方法也与前面的queue lookahead相结合，可以很好的解决HOL的问题。

第三种就是采用per-output-queue input queue（VOQ）的方法，就是在输入模块为每个output port建立单独的queue，结构如下图所示：

不解释。

接下是最后的output path。