Soul Orbit

I'll take a quiet life. A handshake of carbon monoxide.

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

1. 物理层(Physical Layer)

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

Read more »

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

1. PCIe协议栈

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

Read more »

上一篇中,我们简单的介绍了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。

Read more »

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为主。

那我们就开始吧!

Read more »

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}$

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

Read more »

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

Read more »

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

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

Read more »

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

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

1. 核心仓库

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

Read more »

在上一篇文章中,我们简单的介绍了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的文档有很大的帮助。

Read more »

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

1. 为什么要做SONiC

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

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

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

Read more »
0%