Soul Orbit

在看完事务层和数据链路层之后，我们来继续我们的协议栈之旅吧！这一篇中，我们会来看看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目录下。我们这里就来看看这两种通信机制的实现吧！

在上一章中，我们了解了SONiC的整体设计和核心组件，为我们提供了一副看代码的地图，所以这一章，我们就来从代码的级别来继续了解SONiC吧！

SONiC的代码都托管在GitHub的sonic-net账号上，仓库数量有30几个之多，所以刚开始看SONiC的代码时，肯定是会有点懵的，不过不用担心，我们这里就来一起看看～

1. 核心仓库

首先是SONiC中最重要的两个核心仓库：SONiC和sonic-buildimage。

在上一篇文章中，我们简单的介绍了SONiC的基本架构，以及它的一些特点。在这篇文章中，我们来继续自上向下的来看看SONiC，更加深入一点的来了解SONiC的核心组件的构成。

1. 前置知识

这篇文章和SONiC的官方文档中会经常出现这几个词：ASIC（Application-Specific Integrated Circuit）和ASIC状态（State）。它们指的是交换机中用来进行包处理的Pipeline的状态，比如，ACL，转发方式等等，这个和其他交换机的硬件状态，比如，端口状态（端口速度，接口类型），IP信息等等硬件状态是非常不同的。如果大家有兴趣了解更深入的细节，可以先移步阅读两个相关资料：SAI (Switch Abstraction Interface) API和一篇RMT（Reprogrammable Match Table）的相关论文：Forwarding Metamorphosis: Fast Programmable Match-Action Processing in Hardware for SDN。这些都会对我们阅读SONiC的文档有很大的帮助。

这几天都在看和SONiC相关的资料，所以按照习惯，这里也简单的对学习的结果进行一个总结，希望也能对其他对SONiC感兴趣的小伙伴有所帮助。

1. 为什么要做SONiC

我们知道交换机内部都有一套可大可小的操作系统，用于配置和查看交换机的状态。但是，从1986年第一台交换机面世开始，虽然各个厂商都在进行着相关的开发，到现在为止种类也相当的多，但是依然存在一些问题，比如：

1. 生态封闭，不开源，主要是为了支持自家的硬件，无法很好的兼容其他厂商的设备
2. 支持的场景很有限，难以使用同一套系统去支撑大规模的数据中心中复杂多变的场景
3. 升级可能会导致网络中断，难以实现无缝升级，这对于云提供商来说有时候是致命的
4. 设备功能升级缓慢，难以很好的支持快速的产品迭代

所以，微软在2016年开源了SONiC，希望能够通过开源的方式，让SONiC能够成为一个通用的网络操作系统，从而解决上面的问题。而且，由于Azure的背书，也能保证SONiC确实能够承受大规模的生产环境的考验，这也是SONiC的一个优势。