2022.10.19 回顾

计划惨遭滑铁卢，还是随便点，整个回顾专题，想回顾就回顾。

工作：

一个问题：网络包整个流程发生了什么

• 现在搞的ovs的东西，但是ovs却是非常复杂，不只是在于ovs的整个架构，在于怎样知道ovs在整个网络中所处的位置，一个网络包，从软件到硬件，经历了什么完成了信息的传输，实在是很多ovs之外的东西。我想知道在云网络里，当一个数据包从网卡里出去，到底经历了什么然后再接受返回的数据包，发出去是大二层overlay网络的发送流程吗？对方收到后，ssl怎么计算的？是计算整个网络包吗？从网卡到内存是通过DMA么，NUMA的内存控制在那个部分？dpdk从网卡拿包送到用户态，ovs查完流表，执行的ct是神马，封装vxlan是什么时候执行的？ 

工作思考：

再过不到一个月要转正中期答辩，在25分钟内介绍完自己的产出。当说一件东西的时候，要先说这件东西的由来，我从哪里来，我是谁，我到哪里去，所有的东西都可以这般思考，有因有果。

• 最开始做那个acl算法的时候，因为dpdk原生的算法内存开销太大，业务规则多导致他们项目的内存占用很高，dpdk内存这块是大头，当时mentor给说了hypersplit算法，有个基础版的实现，这个论文也是很久之前的了，但是存在一些问题，算法实现也有些bug，做了一些工作，最后同步dpdk的api，可以选择算法是使用dpdk的还是hypersplit的。由来是内存，用了个新的算法牺牲2倍的性能去换取十倍的内存，未来是如果性能还不满意，那么最后可以通过sse指令进行最后的比较，最后的比较耗时占了大头。
• 一个是MMC缓存的工作，这个来源于实习的时候我做过流表查询的分享，对这部分的代码比较熟悉，然后mentor有这个想法，我就去做了，在落地的时候有很多细节的东西，比如sse效果如何，hash选取几位比较好，一个桶里面有几个entry比较好，在那个里prefetch比较好，最后经过了一些尝试，发现sse性能并不好，通过top perf命令发现瓶颈都在内存访问，经过一些测试，MMC的优势就在于当megaflow很多的时候，测试环境是100w打流，性能没有区别，可是smc的缓存率只有47%，而MMC可以百分百，为什么呢？因为MMC一个bucket可以存16个，而SMC只能存4个，MMC可以解决更多的hash冲突，这个用途是什么呢？现在有很多机器开了ipv6发现流变多了，直接导致megaflow数量剧增，然后smc缓存就会下降，影响性能，而MMC可以提高缓存命中率，但是为什么测试时命中率差那么多性能却近乎一样？我尝试了把SMC也关闭，发现全部去查megaflow速度也一样，通过命令发现，都是在第一个subtable里查到，这是因为添加的4w条规则只有目的端口不一样，所以都在一个subtable里，很难模拟出线上环境去测试，后续mentor还要添加plugin，可以插件化哈希函数，这个工作就先收尾了。等着后续plugin完成，再搭环境进行一些优化，比如知道了访存的消耗，那么一个batch一个batch地查找，一次性prefetch一个batch的包，会不会更好。
• 端口调度组，做这个东西源自于微突发导致pmd循环处理物理网口的速度太慢，网卡队列移除，产生丢包，有几种解决方法，一是调大网卡队列长度使网卡可以缓存更多网络包，二是加快包处理流程以便于更快地去网卡拿包，三就是加快pmd对物理口的轮训速度，现在已经把队列长度调到4096，默认把EMC关闭，SMC打开，然后我做的工作就是增加一个端口调度的功能。当虚拟机的虚拟网卡队列比较多的时候，可以把物理网口和虚拟网口绑定到不同的调度组上，每个调度组可以设置权重，pmd不再轮训所有网口，而是轮训每个调度组，这样可以自己配置pmd去轮训虚拟口和物理口的权重。但是实现起来蛮复杂的，一是ovs的分层结构，最上层bridge，然后ofproto层， 然后dpif层，然后datapath层，然后netdev层，这里参考了flc的实现方法，利用netdev里面的args字段实现从bridge设置，再dpif-netdev层可以访问；二是需要考虑非常多的情景，设置了一个不存在的调度组，所在的调度组被删了，更改调度组的同步，如何最小影响地更改调度组权重，PMD最后轮训调度组的时候，怎样访问poll_queue比较方便？对于调度组，设置了一个默认不可被删除的调度组，如果所在的调度组被删除了，就会迁移到默认的调度组上。而且每次对调度组进行增删，都会更改调度组的消息变量，每次在dpif-netdev层设置了调度组，都会更新调度组的消息变量，这样当端口配置的调度组从不存在到存在，就可以获知消息从而绑定上。当修改port绑定的调度组的时候，需要重新重新配置pmd的调度组，其代价很大，对于如何付出最小的代价去更改weight，有天晚上突然想到，这种分层的关系，上层修改，通知下层，下层再做修改，那么其实就是上层完全可以连带下层的一起修改，于是我在vswitch进程里更改port对应调度组时，就通过原子操作修改weight，pmd轮训调度组时，通过原子操作读weight，这样当修改weight的时候就不需要重配pmd的调度组了。对于如何每次轮训调度组只会访问调度组所在的队列呢？为了最小地改动代码，我在每个队列数组里加一个“下一个要轮训的队列的下标”变量，这样可以只需要更改非常少量的代码，就可以让pmd达到每次对调度组执行weight次的poll效果。最后的测试的结果是可以是miss error减少40%，如果加上hook，可以减少100%。
• 自动升级脚本，之前升级整个过程需要一直人盯着，上次升级两周每天下午时间全在升级机器，反复就是几个命令，偶尔还会因为numa数量的不一致用错命令，耗费人力还容易出错。除去ping的过程，每次都都需要执行4次命令，过程十分缓慢，一批升级下来可能需要5分钟，这次又要升级2w太机器，耗时三个月，如果按照之前那种升级方式，我们每个人可能有一个半月什么东西都做不了，就在升级机器，然后我就想如何让升级自动化，想了几天，给mentor说了下方案，利用上之前同事的脚本，花了一周做了个自动化升级。十一回来后已经用上这个脚本，首先是升级速度快了几倍，因为不再是需要人工检查，中间没有肉眼检查的耗时，还优化了两部分的检查方案，仅仅升级流程上少了一半的耗时。最重要的是自动化后不会影响个人的办公，当有机器升级失败会直接通过机器人发送告警，也可以即使响应，去处理升级失败的机器。

一些计划：

　　因为组里没有测试同学，测试搭建环境复杂，也很难模拟复杂的网络环境->找一下测试过的同学，咨询一下他们的测试方法，查看性能测试的文档，看一下环境，搞出来一套标准化的测试流程

　　文档分散，入门困难->工作回顾+文档整理

　　因为是应届生，很多东西都是第一次接触，ovs又是一个非常复杂的东西，让我感觉到一点非常重要但是我又薄弱的是，我不了解整个系统的流程，比如我知道ovs的网络包查找的流程，ovs的pmd如何配置生成的，但是不知道offload怎么做的，对dpdk了解更少，无法把ovs-dpdk嵌入整个网络流程中，之后要先尽快建立起这些知识的框架，多和mentor和同事交流，然后填补空缺。 

原文地址：http://www.cnblogs.com/philo-zhou/p/16807708.html