OVS响应OFPT_FLOW_MOD过程分析

整理处理流程图:

1. 通过对of msg进行解码,可以得到具体的flow_mod以及对应的actions,(这里看增加流表的情况),接下来add_flow函数就会根据flow_mod制定的流来构建特定的规则分类器,增加到oftable中。具体过程是:选择一个合适的表;构建一个分类规则(关键代码如下);插入。这样此次通信的任务就完成了,当再有packet因为在datapath层匹配失败上传到用户空间时,就会找到oftable中的分类规则,从而执行其中的动作。

cls_rule_init(&rule->cr, &fm->match, fm->priority);

rule->ofproto = ofproto;

rule->created = rule->modified = rule->used = time_msec();

rule->idle_timeout = fm->idle_timeout;

rule->hard_timeout = fm->hard_timeout;

rule->table_id = table - ofproto->tables;

rule->send_flow_removed = (fm->flags & OFPFF_SEND_FLOW_REM) != 0;

rule->ofpacts = xmemdup(fm->ofpacts, fm->ofpacts_len);

rule->ofpacts_len = fm->ofpacts_len;

rule->evictable = true;

/* Insert new rule. */

victim = oftable_replace_rule(rule);

2. 解码的过程是根据消息头中长度信息,以及action长度,类型字段得到对应的实体。

关键代码为:

if (raw == OFPRAW_OFPT10_FLOW_MOD) {

const struct ofp10_flow_mod *ofm; //1.0协议

enum ofperr error;

ofm = ofpbuf_pull(&b, sizeof *ofm);   /* Get the ofp10_flow_mod. */

/* Translate the rule. */

ofputil_match_from_ofp10_match(&ofm->match, &fm->match);

//将刚才解析出来的ofm转换成通用的ofputil_flow_mod;

ofputil_normalize_match(&fm->match);

error = ofpacts_pull_openflow10(&b, b.size, ofpacts); /* Now get the actions. */

/* OpenFlow 1.0 says that exact-match rules have to have the  highest possible priority. */

fm->priority = (ofm->match.wildcards & htonl(OFPFW10_ALL)

? ntohs(ofm->priority)

: UINT16_MAX);

/* Translate the message. */

command = ntohs(ofm->command);

fm->cookie = htonll(0);

fm->cookie_mask = htonll(0);

fm->new_cookie = ofm->cookie;

fm->idle_timeout = ntohs(ofm->idle_timeout);

fm->hard_timeout = ntohs(ofm->hard_timeout);

fm->buffer_id = ntohl(ofm->buffer_id);

fm->out_port = ntohs(ofm->out_port);

fm->flags = ntohs(ofm->flags);

3. 上述完成add flow之后,用户空间的分类表得到了更新。此时如果对应的packet到达时,struct rule_dpif *rule = rule_dpif_lookup(ofproto, &miss->flow);

就会找个相应的规则,facet的创建依赖于它。

OVS响应OFPT_FLOW_MOD过程分析

时间: 2024-10-25 06:38:00

OVS响应OFPT_FLOW_MOD过程分析的相关文章

OVS 响应 OFPT_SET_CONFIG 过程分析

ovs 对于 OFPT_SET_CONFIG消息的处理过程非常简单,其实就是通过TCP协议(或其它)交换了几个整型值,而且交换机不需要对此消息进行回复:只需要解析出消息体(struct ofp_switch_config)然后设置max miss  len 即可.通过分析Floodlight发送它的过程 和 OVS 处理它的过程,我们可以对openflow协议有更好的理解.下面是代码流程: 对于这个消息的具体处理: static enum ofperr handle_set_config(str

OVS处理upcall过程分析

处理upcall的整体框架是: 1.由函数handle_upcalls()批量处理(in batches)的是由内核传上来的dpif_upcalls,会解析出upcall的类型.这里主要看在内核中匹配流表失败的MISS_UPCALL.处理完成后会得到多个flow_miss. 结构体dpif_upcall代表的是由内核传到用户空间的一个包,包括上传原因,packet data,以及以netlink attr形式存在的键值. struct dpif_upcall { /* All types. */

OVS中arp响应的流表的实现

总结: 1.br-int 流表总体是按照Normal 的方式,即常规的交换机的转发方式进行转发.而br-tun 交换机则主要按照流表的方式进行转发. 2.一般情况下,VM发出的ARP请求,会在该VM的所有邻居进行广播发送和查找,大量浪费带宽.当neutron开启了l2 pop后(二次注入功能), 计算节点会学习别的主机发送的免费ARP, 从而在本地存在ARP表项. 3.当本地的VM发出ARP请求时,br-tun交换机会优先查找本地的ARP表项,从而对报文进行ARP应答. 这样的话,就不用发出AR

OVS流表查询过程分析

OVS中流表操作的理解关键在于这里哈希表的实现,引入的 flex_array方便了内存的管理,通过 hash&(桶数-1)可以随机的将一个元素定位到某一个桶中. 接下来是代码细节. 一. 核心数据结构 //流表 struct flow_table{ struct flex_array * buckets; //具体的流表项 unsigned int count , n_buckets ; // struct rcu_head rcu; int node_ver; //node_ver的存在使得我

OpenVswitch(OVS)源代码分析之简介

云计算是现在IT行业比较流行的,但真正什么是云计算业界也没有个什么统一的定义(很多公司都是根据自己的利益狭隘的定义云计算),更别说什么标准规范了.所以现在就有很多人说云计算只不过是个幌子,是个嘘头,没点实用的,嘴上说说而已,虽然我也不太清楚什么叫做云计算,云计算的定义究竟是什么,但我根据我公司现在做的云计算产品来说,对于云计算服务还是懂些的.我觉得那并不是什么幌子.嘘头,但如果说这云计算技术还不太成熟,我倒还勉强认可的.若把云计算比作一个人的话,我个人觉得现在它正是二十岁的样子,到三十多岁就算是

标量滤波的过程分析和证明及C实现

摘要: 标量滤波的过程分析和证明及C实现,希望能够帮助入门的小白,同时得到各位高手的指教.并不涉及其他Kalman滤波方法. 本文主要参考自<A Introduction to the Kalman> (需要的同学可以自行百度,也可以找到中文版的) 注:递归思想,高斯分布独立性的应用,数据融合的应用 一,什么是Kalman 滤波(已经了解的同学可以跳过这里) 卡尔曼在博士期间发表了用递归方法解决离散数据线性滤波 问题的论文(关于Kalman 滤波的真正第一人还是有待探讨的,有兴趣的同学自行查找

HDFS读文件过程分析:读取文件的Block数据

转自http://shiyanjun.cn/archives/962.html 我们可以从java.io.InputStream类中看到,抽象出一个read方法,用来读取已经打开的InputStream实例中的字节,每次调用read方法,会读取一个字节数据,该方法抽象定义,如下所示:public abstract int read() throws IOException;Hadoop的DFSClient.DFSInputStream类实现了该抽象逻辑,如果我们清楚了如何从HDFS中读取一个文件

Chromium的Plugin进程启动过程分析

前面我们分析了Chromium的Render进程和GPU进程的启动过程,它们都是由Browser进程启动的.在Chromium中,还有一类进程是由Browser进程启动的,它们就是Plugin进程.顾名思义,Plugin进程是用来运行浏览器插件的.浏览器插件的作用是扩展网页功能,它们由第三方开发,安全性和稳定性都无法得到保证,因此运行在独立的进程中.本文接下来就详细分析Plugin进程的启动过程. 老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注! 在Chro

Android应用程序UI硬件加速渲染的Display List构建过程分析

在硬件加速渲染环境中,Android应用程序窗口的UI渲染是分两步进行的.第一步是构建Display List,发生在应用程序进程的Main Thread中:第二步是渲染Display List,发生在应用程序进程的Render Thread中.Display List是以视图为单位进行构建的,因此每一个视图都对应有一个Display List.本文详细分析这些Display List的构建过程. 老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注! 这里说的D