Soul Orbit

（以下内容已经整合进《SONiC入门指南》的 BGP路由变更下发 一节中。）

在上一篇中，我们介绍了BGP路由变更的工作流中从bgpd到fpmsync的部分，本篇我们将继续介绍剩下的BGP路由变更的下发流程。

1. SONiC路由变更工作流

当FRR变更内核路由配置后，SONiC便会收到来自Netlink和FPM的通知，然后进行一系列操作将其下发给ASIC，其主要流程如下：

sequenceDiagram
    autonumber
    participant K as Linux Kernel
    box lightyellow bgp容器
    participant Z as zebra
    participant FPM as fpmsyncd
    end
    box pink database容器
    participant R as Redis
    end
    box lightblue swss容器
    participant OA as orchagent
    end
    box lightgreen syncd容器
    participant SD as syncd
    end
    participant A as ASIC

    K->>FPM: 内核路由变更时通过Netlink发送通知
    Z->>FPM: 通过FPM接口和Netlink<br/>消息格式发送路由变更通知

    FPM->>R: 通过ProducerStateTable<br/>将路由变更信息写入<br/>APPL_DB

    R->>OA: 通过ConsumerStateTable<br/>接收路由变更信息
    
    OA->>OA: 处理路由变更信息<br/>生成SAI路由对象
    OA->>SD: 通过ProducerTable<br/>或者ZMQ将SAI路由对象<br/>发给syncd

    SD->>R: 接收SAI路由对象，写入ASIC_DB
    SD->>A: 通过SAI接口<br/>配置ASIC

（以下内容已经整合进《SONiC入门指南》的 BGP工作流 ，BGP命令实现和BGP路由变更下发 三节中。）

BGP可能是交换机里面最常用，最重要，或者线上使用的最多的功能了。这一篇，我们就来深入的看一下BGP相关的工作流。

1. BGP相关进程

SONiC使用FRRouting作为BGP的实现，用于负责BGP的协议处理。FRRouting是一个开源的路由软件，支持多种路由协议，包括BGP，OSPF，IS-IS，RIP，PIM，LDP等等。当FRR发布新版本后，SONiC会将其同步到SONiC的FRR实现仓库：sonic-frr中，每一个版本都对应这一个分支，比如frr/8.2。

FRR主要由两个大部分组成，第一个部分是各个协议的实现，这些进程的名字都叫做*d，而当它们收到路由更新的通知的时候，就会告诉第二个部分，也就是zebra进程，然后zebra进程会进行选路，并将最优的路由信息同步到kernel中，其主体结构如下图所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

+----+  +----+  +-----+  +----+  +----+  +----+  +-----+
|bgpd|  |ripd|  |ospfd|  |ldpd|  |pbrd|  |pimd|  |.....|
+----+  +----+  +-----+  +----+  +----+  +----+  +-----+
     |       |        |       |       |       |        |
+----v-------v--------v-------v-------v-------v--------v
|                                                      |
|                         Zebra                        |
|                                                      |
+------------------------------------------------------+
       |                    |                   |
       |                    |                   |
+------v------+   +---------v--------+   +------v------+
|             |   |                  |   |             |
| *NIX Kernel |   | Remote dataplane |   | ........... |
|             |   |                  |   |             |
+-------------+   +------------------+   +-------------+

（以下内容已经整合进《SONiC入门指南》的 SAI介绍 和 Syncd-SAI工作流 两节中。）

Syncd容器是SONiC中专门负责管理ASIC的容器，其中核心进程syncd负责与Redis数据库沟通，加载SAI并与其交互，以完成ASIC的初始化，配置和状态上报的处理等等。

由于SONiC中大量的工作流最后都需要通过Syncd和SAI来和ASIC进行交互，所以这一部分也就成为了这些工作流的公共部分，所以，在展开其他工作流之前，我们先来看一下Syncd和SAI是如何工作的。

在看完事务层和数据链路层之后，我们来继续我们的协议栈之旅吧！这一篇中，我们会来看看PCIe物理层（Physical Layer）是如何工作的，从而帮助我们更加深入的了解PCIe的数据传输。

1. 物理层（Physical Layer）

当数据链路层将上层数据封装好后，就会将其交给物理层进行传输。而物理层的主要目的将数据转换为易于介质传输的电信号，并发送出去，或者将接收到的转换后的信号，转变为上层能处理的数据包。其主要结构如下：

在上一篇中，我们介绍了PCIe设备的配置空间，及其设计的目的，最后我们说到了消息路由的设计。所以，这一篇我们就继续这个话题，来看看PCIe设备之间的通信方式吧。

1. PCIe协议栈

PCIe是以包（Packet）为单位传输数据的。和计算机网络类似，其协议也是分层的。其协议栈主要分为三层：物理层（Physical Layer），数据链路层（Data Link Layer）和事务层（Transaction Layer），如下图所示：

在上一篇中，我们简单的介绍了PCIe的总体架构，设备树和主要组成部分，并且了解了如何通过lspci命令和Windows下的设备管理器来查看PCIe的系统结构。这一篇，我们来更加深入的看看PCIe中的设备相关的信息，如配置空间，来帮助我们了解PCIe和这些命令的工作原理。

1. It is all about memory

理解PCIe的关键，我个人觉得是理解内存的访问。这里先小小的剧透一下，PCIe中主要定义了4种请求：Memory Transaction，I/O request，Configuration Space Access和Message。除了最后一种以外，其余三种全都是基于内存访问的，甚至连中断发起都是基于内存访问的，所以如果我们能很好的理解内存的访问，我们就能很好的理解PCIe。

PCIe的全称是Peripheral Component Interconnect Express，是一种用于连接外设的总线。它于2003年提出来，作为替代PCI和PCI-X的方案，现在已经成了现代CPU和其他几乎所有外设交互的标准或者基石，比如，我们马上能想到的GPU，网卡，USB控制器，声卡，网卡等等，这些都是通过PCIe总线进行连接的，然后现在非常常见的基于m.2接口的SSD，也是使用NVMe协议，通过PCIe总线进行连接的，除此以外，Thunderbolt 3 [2]，USB4 [3]，甚至最新的CXL互联协议 [4]，都是基于PCIe的！

所以一旦开始往设备相关的开发上面走了之后，PCIe可以算是一个绕不过的坎。这几天看了一些和PCIe相关的资料，这里简单的总结一下，也希望对大家有所帮助。这篇文章主要会聚焦在硬件的部分，和操作系统本身没有什么太大的关系，无论是Windows还是Linux，底层的部分都是非常类似的，文章中也会提到调试的方法，不过会主要以Linux为主。

那我们就开始吧！

Hexo虽然可以通过一些方法来支持MathJax，比如next主题或者Hexo Filter MathJax，但是它们都提到了默认renderer的兼容性问题，并且说最好是换成pandoc，不过我切换成pandoc之后所有的页面渲染却全都失败了……整个博客都瘫痪了，正当我快放弃的时候，突然发现hexo-renderer-markdown-it好像兼容的还不错，所以遇到了类似问题的小伙伴，可以也试一试这个～

以下是一些常用的测试和效果：

• _会被hexo-renderer-marked转义导致失败：
  • $\epsilon_0$：$\epsilon_0$
• *会被转义导致失败
  • $\begin{eqnarray*}\nabla\cdot\vec{E}&=&\frac{\rho}{\epsilon_0}\end{eqnarray*}$：$\begin{eqnarray*}\nabla\cdot\vec{E}&=&\frac{\rho}{\epsilon_0}\end{eqnarray*}$
• 其他一些测试：
  • $\frac{\partial}{\partial t}$：$\frac{\partial}{\partial t}$

这里可以看到，即便是使用"`"包裹的代码，也没有什么问题！挺好～

画数字时序图怎么能没有WaveDrom呢？所以必须整一个！给正在用的Hexo皮肤Next添加了WaveDrom的支持，现在可以在文章中直接使用WaveDrom了！效果如下：

在大概了解了各个服务和源码仓库之后，相信大家已经对可以开始自如的浏览SONiC的源码了，所以这一篇文章中，我们就来看看SONiC中最常用的组件 - 通信机制。

SONiC中主要的通信机制有两种：与内核的通信和基于Redis的服务间的通信。所有的实现都在sonic-swss-common这个repo中的common目录下。我们这里就来看看这两种通信机制的实现吧！