switch architecture and pipeline

感觉自己写这个有点班门弄斧，但为了知识体系完善，体系完善了好记住，硬着头皮写，写到什么程度算什么，理解不深，瞎扯蛋的成分比较多，大家不要笑话。

分组交换来自于电话网络，先接通接话员告诉接话员要和哪里通话，接话员那帮忙接通对方，后来就发展出机械设备代替了接话员，再后来出现的电子技术设备进行转接，能同时支持的话路更多。打电话是模拟信号，而且是线路资源预留，分组交换是数字信号，是一个个分组交换，每一个分组交换和电话转接时用到的技术类似。

基础交换技术

• head of line blocking和queue

两个不同的port进来两个报文要同时从一个port出去，这两个报文就会竞争这个出port，出port就要有queue，把一个报文存进去。

• non-blocking switch

交换机有4个port，分别是port1,port2,port3和port4，第一组报文从port1进port2出，第二组报文从port3进port4出，对这两组报文的转发互不影响就是non-blocking。

• crossbar

也就矩阵交换，N行和N列交叉，通过控制交叉点的开关达到N进N出non-blocking switch。

• clos

就是把一堆crossbar连接在一起，达到更多进更多出的non-blocking switch效果。

交换机硬件

交换机硬件很复杂，有专利和商业机密保护，水很深，芯片厂商会给设备厂商出参考设计，都有NDA保密，啥都不公开，全靠瞎猜测。

• switch chip

负责转发，有很多复杂的转发逻辑，软件会给芯片下转发表项，芯片也会自己学习，各种表项有空间限制。

• 通用CPU

运行协议程序，协议太复杂了，不适合芯片处理，软件需要给芯片注册，把协议报文上送CPU处理，有CPU总得有内存，有内存总得有总线，内存要不要共享，上送哪个CPU，CPU怎么分工，芯片怎么把报文传到内存中，每家交换机都不同。

• 盒式交换机

OCP终于有一点公开的资料了，《Broadcom-OCP-Trident2-leaf-spine》，按这个文档中的图，XLP和AMD不共享内存，各有各的总线，芯片决定把报文上送不同的CPU，芯片和CPU之间有很多类型的接口，带宽很大。

• 框式交换机

有主板/备板/N块接口板/背板/网板，太复杂了，CPU在哪里内存在哪里转发芯片在哪个板上，什么样的连接关系，已经超出我对计算机体系结构的理解了。

交换机软件

一般厂商都有自己的操作系统作为平台，芯片厂商提供SDK，产品部做个驱动包装SDK给平台注册钩子，这样平台就可以对接多个厂商的芯片，不同的芯片加平台就可以包装出各种型号的产品。操作系统一般基于linux内核裁剪，再移植bsd的tcp/ip协议处理模块，加入TIPC实现不同板通信，操作系统比一般linux发行版要稳定很多，要经过残酷的测试，十年八年不重启不死机。操作系统内核有软转发FIB和快转表，MAC管理/IP管理/IF管理等等，用户态一堆协议进程，有RIB有DBM等，整体上支持graceful restart/在线不断流升级/HA等等，每一行代码review无数次，各自动态静态工具检查，代码鉴定，N轮测试，质量扛扛的。再看linux+ovs或者linux+vpp+dpdk，质量确实不行。

pipeline

用说我对pipeline的理解，pipeline这个词理解被用烂了，如同云一样。协议是标准的，报文格式是固定的，具体怎么实现是灵活的，最终效果达到就行了。

pipeline处理acl/mirror/l2 lookup/l3 lookup很成熟，但有了tunnel就不一样了。

交换芯片pipeline分为parser stage，多层头都解析完了，再查表项转发，可能和软件实现的思维都不一样，芯片的pipeline也是不断完善的，曾经做完一个项目是trill三层卸载，就是trident II做完trill decap后不能再l3 lookup了，有人说用一根线回环一下，trill decap后从一个口出去，再从另一个口进来l3 lookup，更有高人出了个方案，出三层的报文不再进行trill encap，把网关mac做特殊标记，ingress设备不做trill encap，而且网关还能主主多活，牛逼的一塌糊涂，后来新的芯片这个问题就解决了，看来芯片厂商实现新功能也容易，要不也不会出这样一款芯片。

vpp pipeline不断砍头，始终记住此时eth_header在哪一层,ip_header在哪里，不断前进不断砍头，也有可能在pipeline上多转几圈。

openflow pipeline几层封装,flow key的生成，flow key中加tunnel信息，recirc查找，action在积累，最后执行，如果后面的match依赖于前面action的结果，不得不先执行这些action。假如要实现NSH，研究哪个openflow标准支持，那个版本的ovs实现了nsh解释和动作，好处是标准，厂商能互通，但硬件实现成本高。

p4 pipeline parser一下把头都解封装了，把各层key都提取出来，然后match不同的key再action，甚至报文可以不按rfc封装，自己封装，自己识别就行了，key也可以自己定义，match和action自己编程实现，扩展已有协议也容易，协议无关编程，两个p4交换机能互相识别就行了，坏处私有实现不能互通。体系无关，类似于c和gcc，还有x86 arm等arch，一份p4程序，不同编译的版本能在不同的芯片上运行。