OpenvSwitch系列之flow_mod

来源：互联网发布：java面试项目介绍范文编辑：程序博客网时间：2024/05/17 22:36

最近两周一直在研究flow_mod这个消息，flow_mod这个消息是openflow中最重要的消息，没有之一，所以花在它的时间上比较多，而且里面涉及的内容也比较复杂。社区有一篇博文对我帮助还是很大。因此这边可能和他的文章有一部分冲突，但是对于学习和总结无所谓啦！！

我们在上一篇中有介绍了，OpenvSwitch是如何进行不同openflow协议版本的控制的，也知道了入口函数是handle_openflow__，本文的主题是flow_mod消息，因此我们直接进入flow_mod处理函数。

众所周知，flow_mod是用于下发流表的。可以简单理解为一个flow_mod就是就是一个流表项。如果有谁不是很了解flow_mod，请自行阅读openflow协议。

通过入口函数openflow_handle__可以知道flow_mod处理函数是，为了描述相对清晰，我会在代码中直接进行注释，除了需要特别指出或者着重描写才在博文中单独写出来。

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
static enum ofperr
handle_flow_mod(struct ofconn *ofconn, const struct ofp_header *oh)
    OVS_EXCLUDED(ofproto_mutex)
{
    /* 每一个ofproto代表一个交换机，并且挂在ofconn连接中，
     * 如果有谁不知道其中关联关系，请参考我的第三篇文章。
     * 因此第一步就需要获取openflow交换机对象，即ofproto
     */
    struct ofproto *ofproto = ofconn_get_ofproto(ofconn);
    struct ofputil_flow_mod fm; /* flow mod 消息 */
    uint64_t ofpacts_stub[1024 / 8];
    struct ofpbuf ofpacts;
    enum ofperr error;
    error = reject_slave_controller(ofconn); /* 角色权限验证我们可以忽略。 */
    if (error) {
        goto exit;
    }
    /* 将stub挂在ofpbuf中这个地方经常见到不再详细分析有不明白的可参考前面几篇*/
    ofpbuf_use_stub(&ofpacts, ofpacts_stub, sizeof ofpacts_stub);
/* flow_mod解码解码过程其实很简单，只要按照标准协议格式一个字段一个字段
* 解析就可以啦！！这里我们按照某一种报文进行讲解，这样对于代码理解帮助非常有
* 意义，也不至于会有这样的疑问，为什么这样写？？哈哈哈
*/
    error = ofputil_decode_flow_mod(&fm, oh, ofconn_get_protocol(ofconn),
                                    &ofpacts,
                                    u16_to_ofp(ofproto->max_ports),
                                    ofproto->n_tables);
    /* 校验action内容 */
    if (!error) {
        error = ofproto_check_ofpacts(ofproto, fm.ofpacts, fm.ofpacts_len);
    }
   
    if (!error) {
        error = handle_flow_mod__(ofproto, ofconn, &fm, oh); /* 真正处理flow_mod函数 */
    }
    if (error) {
        goto exit_free_ofpacts;
    }
   
    /*
     * 修改统计值大概是为了控制器下发统计请求用的吧!!
     */
    ofconn_report_flow_mod(ofconn, fm.command); /* 释放内存，这里不会真正调用free函数的 */
exit_free_ofpacts:
    ofpbuf_uninit(&ofpacts);
exit:
    return error;
}

上面是flow_mod函数处理框架，下面我们进行逐个分析，我们进行分析时候会结构flow_mod消息，因此有具体的消息内容，我们在分析代码的时候不至于那么抽象。

下面报文就是我抓取的，比较有针对性，控制器下发的流表是从host1到host2，出端口是交换机的2。具体报文和网络拓扑如下：

注：红色线就是打通的通道。
由于函数ofputil_decode_flow_mod相对较长，因此采用分段描述，层层深入方式进行剖析。

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
/* Converts an OFPT_FLOW_MOD or NXT_FLOW_MOD message 'oh' into an abstract
 * flow_mod in 'fm'.  Returns 0 if successful, otherwise an OpenFlow error
 * code.
 *
 * Uses 'ofpacts' to store the abstract OFPACT_* version of 'oh''s actions.
 * The caller must initialize 'ofpacts' and retains ownership of it.
 * 'fm->ofpacts' will point into the 'ofpacts' buffer.
 *
 * Does not validate the flow_mod actions.  The caller should do that, with
 * ofpacts_check().
 * OpenvSwitch支持两种flow格式，一种标准flow_mod，一种NXT flow_mod.
 * 对于OpenvSwitch来说无论是哪种flow_mod，经过ovs抽象之后都会转成
 * struct ofputil_flow_mod进行存储。
 */
enumofperr
ofputil_decode_flow_mod(structofputil_flow_mod*fm,
                        conststructofp_header*oh,
                        enumofputil_protocolprotocol,
                        structofpbuf*ofpacts,
                        ofp_port_tmax_port,uint8_tmax_table)
{
    ovs_be16raw_flags;
    enumofperrerror;
    structofpbufb;
    enumofprawraw;
    /* 将flow_mod消息挂载在ofpbuf的b中 */
    ofpbuf_use_const(&b,oh,ntohs(oh->length));
/* 解析消息头前面有一篇介绍OpenvSwitch是如何进行版本兼容。*/
raw=ofpraw_pull_assert(&b);

上面内容相对简单，也不用多说些。下面是我们进行着重分析的。由于我们基于openflow1.3进行连接的，因此raw实际值是OFPRAW_OFPT11_FLOW_MOD。（opeflow1.1之后版本flow_mod没有变化。）在这里就有if-else判断，所以我们会着重分析if分支。
一般情况下，flow_mod消息主要是由openflow固定字段，match字段，instruction字段(可以没有)，然而match字段中可以包含多个oxm字段(可以没有oxm)，instruction字段中可以包含多个action字段。其中oxm格式是TLV(Type-Length-Value)。针对上面的报文来说，oxm有两个，action只有一个。所以我们能够预测if分支中主要是针对这些字段进行解析。

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
if (raw == OFPRAW_OFPT11_FLOW_MOD) {
        /* Standard OpenFlow 1.1+ flow_mod. Openflow1.1之后版本flow_mod无变化*/
        const struct ofp11_flow_mod *ofm;
        /* 获取flow_mod固定长度字段头其实是通过指针偏移指向buf，并非申请内存
* 主要是标准flow_mod, 在下面会把ofm相关值赋值到fm中。
*/
        ofm = ofpbuf_pull(&b, sizeof *ofm); /* 从b中移出大小为sizeof(*ofm) */
        /* 获取flow_mod中的match数据赋值到fm->match中
         * 如果存在多个oxm的话，也会同时解析出来的，而且所有的
* oxm做为一个flow流结构
         */
        error = ofputil_pull_ofp11_match(&b, &fm->match, NULL);
        if (error) {
            return error;
        }
        /* 解析instruction数据主要是解析action，将报文中action保存在ofpacts中*/
        error = ofpacts_pull_openflow_instructions(&b, ofpbuf_size(&b), oh->version,
                                                   ofpacts);
        if (error) {
            return error;
        }
        /* Translate the message. Flow_mod固定字段解析。这个地方其实没有什么需要讲解，纯粹赋值。*/
        fm->priority = ntohs(ofm->priority);
        if (ofm->command == OFPFC_ADD
            || (oh->version == OFP11_VERSION
                && (ofm->command == OFPFC_MODIFY ||
                    ofm->command == OFPFC_MODIFY_STRICT)
                && ofm->cookie_mask == htonll(0))) {
            /* In OpenFlow 1.1 only, a "modify" or "modify-strict" that does
             * not match on the cookie is treated as an "add" if there is no
             * match. */
            fm->cookie = htonll(0);
            fm->cookie_mask = htonll(0);
            fm->new_cookie = ofm->cookie;
        } else {
            fm->cookie = ofm->cookie;
            fm->cookie_mask = ofm->cookie_mask;
            fm->new_cookie = OVS_BE64_MAX;
        }
        fm->modify_cookie = false;
        fm->command = ofm->command;
        /* Get table ID.
         *
         * OF1.1 entirely forbids table_id == OFPTT_ALL.
         * OF1.2+ allows table_id == OFPTT_ALL only for deletes. */
        fm->table_id = ofm->table_id;
        if (fm->table_id == OFPTT_ALL
            && (oh->version == OFP11_VERSION
                || (ofm->command != OFPFC_DELETE &&
                    ofm->command != OFPFC_DELETE_STRICT))) {
            return OFPERR_OFPFMFC_BAD_TABLE_ID;
        }
        fm->idle_timeout = ntohs(ofm->idle_timeout);
        fm->hard_timeout = ntohs(ofm->hard_timeout);
        fm->buffer_id = ntohl(ofm->buffer_id);
        error = ofputil_port_from_ofp11(ofm->out_port, &fm->out_port);
        if (error) {
            return error;
        }
        fm->out_group = (ofm->command == OFPFC_DELETE ||
                         ofm->command == OFPFC_DELETE_STRICT
                         ? ntohl(ofm->out_group)
                         : OFPG11_ANY);
        raw_flags = ofm->flags;
} else {
/* 这个else是针对openflow1.0的flow_mod消息进行解析的，我们可以忽略掉 */
}
最后一部分代码，主要内容就是常规校验，我也没有太深入阅读，这里为了保证一致性还是顺便提一下。
/*
 * 保存actions。因为fm是抽象层flow_mod，在最后生成流表项的时候需要这个。
 */
 fm->ofpacts = ofpbuf_data(ofpacts);
 fm->ofpacts_len = ofpbuf_size(ofpacts);
 error=ofputil_decode_flow_mod_flags(raw_flags,fm->command,oh->version, &fm->flags);
 if (error) {
    return error;
}
    if (fm->flags & OFPUTIL_FF_EMERG) {
        /* We do not support the OpenFlow 1.0 emergency flow cache, which
         * is not required in OpenFlow 1.0.1 and removed from OpenFlow 1.1.
         *
         * OpenFlow 1.0 specifies the error code to use when idle_timeout
         * or hard_timeout is nonzero.  Otherwise, there is no good error
         * code, so just state that the flow table is full. */
        return (fm->hard_timeout || fm->idle_timeout
                ? OFPERR_OFPFMFC_BAD_EMERG_TIMEOUT
                : OFPERR_OFPFMFC_TABLE_FULL);
    }
    /* 校验action */
    return ofpacts_check_consistency(fm->ofpacts, fm->ofpacts_len,
                                     &fm->match.flow, max_port,
                                     fm->table_id, max_table, protocol);
} /* 整个函数结束 */

以上就是flow_mod解析函数大体框架，下面我们来看一下match、instruction这两个解析函数。首先我们来看一下函数调用关系图：

根据关系图，从函数3、函数4内容都比较短小，函数也比较容易理解，我们从函数5开始进行分析，分析如下：

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
/*
 * strict – 是否需要严格检查
 * b – 保存match的原始报文buf
 * match – 保存解析后的match  输出参数
 */
staticenumofperr
oxm_pull_match__(structofpbuf*b,boolstrict,structmatch*match)
{
    structofp11_match_header*omh=ofpbuf_data(b);/* 获取match head指针 */
    uint8_t*p;
    uint16_tmatch_len;
    if(ofpbuf_size(b)<sizeof*omh){
        returnOFPERR_OFPBMC_BAD_LEN;
    }
    match_len=ntohs(omh->length);
    if(match_len<sizeof*omh){
        returnOFPERR_OFPBMC_BAD_LEN;
    }
    if(omh->type!=htons(OFPMT_OXM)){
        returnOFPERR_OFPBMC_BAD_TYPE;
    }
   
    /* 尝试将缓冲区b中移除大小为match_len数据
 * 经过下面这个函数处理之后，缓冲区b里面已经没有match相关数据，
 * 剩下就是instruction域
*/
    p=ofpbuf_try_pull(b,ROUND_UP(match_len,8));
    if(!p){
        VLOG_DBG_RL(&rl,"oxm length %u, rounded up to a "
                    "multiple of 8, is longer than space in message (max "
                    "length %"PRIu32")",match_len,ofpbuf_size(b));
        returnOFPERR_OFPBMC_BAD_LEN;
    }
              /*
 * 解析一下这个函数实参：
 * p + sizeof *omh == 跳过match头部
 * match_len - sizeof *omh == 总长度减去match头部长度，即实际报文内容长度。
*/
    returnnx_pull_raw(p+sizeof*omh,match_len-sizeof*omh,
                       strict,match,NULL,NULL);
}

在介绍nx_pull_raw函数之前，我们先看来看一下这个全局数组const struct mf_field mf_fields[MFF_N_IDS]（在文件meta-flow.c），这个数组在下面的函数会用到mf_from_nxm_header。所先把分析一下。

这个虽然数组很长，但是里面的注释对于理解还是有帮助的，数组中是按照网络层次进行划分的，主要是metadata, L2, L2 .5,L3, L4, L5。也就是说根据报文中match字段可得出位于数组的哪层。例如上面报文，是针对物理地址（源/宿mac）那么我们可以推断出是位于数组的L2，如下面代码所示：

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
const struct mf_field mf_fields[MFF_N_IDS] = {
    /* ## -------- ## */
    /* ## metadata ## */
    /* ## -------- ## */
    {
        MFF_DP_HASH, "dp_hash", NULL,
        MF_FIELD_SIZES(be32),
        MFM_FULLY,
        MFS_HEXADECIMAL,
        MFP_NONE,
        false,
        NXM_NX_DP_HASH, "NXM_NX_DP_HASH",
        NXM_NX_DP_HASH, "NXM_NX_DP_HASH", 0,
        OFPUTIL_P_NXM_OXM_ANY,
        OFPUTIL_P_NXM_OXM_ANY,
        -1,
    }, {…
    }
    /* ## -- ## */
    /* ## L2层以太网层 ## */
    /* ## -- ## */
    {/*源mac地址 */
        MFF_ETH_SRC, "eth_src", "dl_src",
        MF_FIELD_SIZES(mac),
        MFM_FULLY,
        MFS_ETHERNET,
        MFP_NONE,
        true,
        NXM_OF_ETH_SRC, "NXM_OF_ETH_SRC",
        OXM_OF_ETH_SRC, "OXM_OF_ETH_SRC", OFP12_VERSION,
        OFPUTIL_P_ANY,
        OFPUTIL_P_NXM_OF11_UP,   /* Bitwise masking only with NXM and OF11+! */
        -1,
    }, {/* 目的mac地址 */
        MFF_ETH_DST, "eth_dst", "dl_dst",
        MF_FIELD_SIZES(mac),
        MFM_FULLY,
        MFS_ETHERNET,
        MFP_NONE,
        true,
        NXM_OF_ETH_DST, "NXM_OF_ETH_DST",
        OXM_OF_ETH_DST, "OXM_OF_ETH_DST", OFP12_VERSION,
        OFPUTIL_P_ANY,
        OFPUTIL_P_NXM_OF11_UP,   /* Bitwise masking only with NXM and OF11+! */
        -1,
    }, {/*以太网类型*/
        MFF_ETH_TYPE, "eth_type", "dl_type",
        MF_FIELD_SIZES(be16),
        MFM_NONE,
        MFS_HEXADECIMAL,
        MFP_NONE,
        false,
        NXM_OF_ETH_TYPE, "NXM_OF_ETH_TYPE",
        OXM_OF_ETH_TYPE, "OXM_OF_ETH_TYPE", OFP12_VERSION,
        OFPUTIL_P_ANY,
        OFPUTIL_P_NONE,
        -1,
    },{…}
  
    /* ## ---- ## */
    /* ## L2.5层 ## */
    /* ## ---- ## */
    {…}
    /* ## ---- ## */
    /* ## L3层 ## */
    /* ## ---- ## */
{…}
} /* 数组结束 */

我们来看一下蓝色字体，这个宏定义
枚举：

C
1
2
3
4
5
6
7
OFPXMT12_OFB_ETH_SRC= 4 
OFPXMT12_OFB_ETH_DST= 3
OFPXMC12_OPENFLOW_BASIC= 0x8000
#define OXM_OF_ETH_SRC        OXM_HEADER   (OFPXMT12_OFB_ETH_SRC, 6)
#define OXM_OF_ETH_DST        OXM_HEADER   (OFPXMT12_OFB_ETH_DST, 6)
#define OXM_HEADER(FIELD, LENGTH) \
    NXM_HEADER(OFPXMC12_OPENFLOW_BASIC,FIELD,LENGTH)

通过上面代码罗列可得知，OXM_HEADER是用于构造报文OXM头部的宏，而OXM是以TLV格式进行封装的。针对上面报文和宏定义就有如下对应（图片蓝色下划线）：

经过函数nxm_do_init处理，会把这个数组中成员挂在全局变量all_fields，这个变量是一个hmap结构，至于这里具体存储关系是怎么关联的，这里不进行详细解析（可以参考函数nxm_do_init）。如果有不理解hmap的网友可以去看一下我之前文章。下面我们继续分析nx_pull_raw函数。

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
/*
 * p -- 指向第一个oxm字段起始内存位置
 * match_len = 整个match字段-match头部长度即所有oxm字段长度，不包括padding
 * strict 是否需要严格检查
 * match  存储match数据(出参)
 */
static enum ofperr
nx_pull_raw(const uint8_t *p, unsigned int match_len, bool strict,
            struct match *match, ovs_be64 *cookie, ovs_be64 *cookie_mask)
{
    uint32_t header;
    ovs_assert((cookie != NULL) == (cookie_mask != NULL));
    match_init_catchall(match); /* init match. */
    if (cookie) {
        *cookie = *cookie_mask = htonll(0);
    }
    if (!match_len) {
        return 0;
    }
   
    /* 我们分析一下for的条件
* 1、可能有多个oxm字段因此需要一个一个遍历
     * 标准里面oxm头部只能说类tlv格式，为什么说是类tlv呢?
     * 标准tlv格式 t和l是两个字节(有的是4个字节)，而oxm中tlv
     * t = 3个字节，l = 1个字节其中t中前两个字节是表示类型，
     * 最后一个字节是又被分成两部分，高7位表示子类型，最后一位代表是否存在mask (根据上面报文可以知道)
     *
     * 2、for循环中魔鬼数字4表示tlv中header字段长度，也就是说header是固长度
     * 3、函数nx_entry_ok 其实是拷贝oxm header部分(4个字节)到变量uint32 header中，对于上面报文中第一个oxm，这个header=0x80000606。
     * 4、宏NXM_LENGTH是用于获取tlv中length值。就是header&0xff。针对上面header是0x80000606，与oxff与操作后正好是6。通过报文查看length的确是6。
     * 5、每解析一次oxm，p就要指向下一个oxm起始位置，match_len就要减去对应长度。
     */
    for (;
         (header = nx_entry_ok(p, match_len)) != 0;
         p += 4 + NXM_LENGTH(header), match_len -= 4 + NXM_LENGTH(header)) {
        const struct mf_field *mf;
        enum ofperr error;
        mf = mf_from_nxm_header(header); /* 从hmap中获取mf，mf这个数组在上面已经介绍过！！这里就不详细介绍了*/
        if (!mf) {
            if (strict) {
                error = OFPERR_OFPBMC_BAD_FIELD;
            } else {
                continue;
            }
        } else if (!mf_are_prereqs_ok(mf, &match->flow)) {
            error = OFPERR_OFPBMC_BAD_PREREQ;
        } else if (!mf_is_all_wild(mf, &match->wc)) {
            error = OFPERR_OFPBMC_DUP_FIELD;
        } else {
            unsigned int width = mf->n_bytes;
            union mf_value value;  /* 这个地方的value是一个联合，设计非常巧妙，可以同时满足各种类型。 */
            memcpy(&value, p + 4, width); /* 将tlv（match）中的value字段赋值到value变量*/
            if (!mf_is_value_valid(mf, &value)) {
                error = OFPERR_OFPBMC_BAD_VALUE;
            } else if (!NXM_HASMASK(header)) {/* 没有设置mask标志会进入此分支针对上面报文，会进入这个分支的！！*/
                error = 0;
                mf_set_value(mf, &value, match); /* 上面已经说过了value是一个联合类型，因此在mf赋值的时候需要进行类型判断，才能正确赋值。 */
            } else {/* 设置了mask标志才会进入else分支 */
                union mf_value mask;
                memcpy(&mask, p + 4 + width, width);
                if (!mf_is_mask_valid(mf, &mask)) {
                    error = OFPERR_OFPBMC_BAD_MASK;
                } else {
                    error = 0;
                    check_mask_consistency(p, mf);
                    mf_set(mf, &value, &mask, match);
                }
            }
        }
/* 下面都一些基本校验，对于业务逻辑没有影响我们不进行深入分析 */
        /* Check if the match is for a cookie rather than a classifier rule. */
        if ((header == NXM_NX_COOKIE || header == NXM_NX_COOKIE_W) && cookie) {
            if (*cookie_mask) {
                error = OFPERR_OFPBMC_DUP_FIELD;
            } else {
                unsigned int width = sizeof *cookie;
                memcpy(cookie, p + 4, width);
                if (NXM_HASMASK(header)) {
                    memcpy(cookie_mask, p + 4 + width, width);
                } else {
                    *cookie_mask = OVS_BE64_MAX;
                }
                error = 0;
            }
        }
        if (error) {
            VLOG_DBG_RL(&rl, "bad nxm_entry %#08"PRIx32" (vendor=%"PRIu32", "
                        "field=%"PRIu32", hasmask=%"PRIu32", len=%"PRIu32"), "
                        "(%s)", header,
                        NXM_VENDOR(header), NXM_FIELD(header),
                        NXM_HASMASK(header), NXM_LENGTH(header),
                        ofperr_to_string(error));
            return error;
        }
    }
    return match_len ? OFPERR_OFPBMC_BAD_LEN : 0;
}

上面分析比较混乱，这里进行一下总结：
1、通过上面这个函数处理(核心代码是for循环)，就会把报文中两个oxm字段解析成功并且保存在入参match里面。
2、我们知道oxm表现形式是一个tlv格式，OpenvSwitch会把value字段赋值到match结构体中的，struct flow(flow.h)结构体。flow这个结构体和mf_fields是有关联关系的。
3、通过上面解析后，flow中字段数据时这样的(实际内存中没有冒号)：
flow.dl_dst[6] = 00:00:00:00:00:02
flow.dl_src[6] = 00:00:00:00:00:01
其他字段是默认值，大部分是0。

通过上面的一系列分析，openflow中的match字段就结束了。现在我们返回到函数ofputil_decode_flow_mod中，下面应该解析instructions。

基于目前OpenvSwitch实现主要支持这6中actions，分别是：openflow1.3中meter表，openflow1.1中apply_action，openflow1.1中clear_action，openflow1.1中write_action，openflow1.1中write_metadata，openflow1.1中goto_table。针对当前的flowmod中action是apply_action，如下图所示：

在介绍函数之前，我们先来看一下函数中即将用到指针数组，const struct ofp11_instruction *insts[N_OVS_INSTRUCTIONS]，通过查看宏定义可知, N_OVS_INSTRUCTIONS=6

默认指针数组中保存地址是null，经过处理后会把其中某个数组存储单元修改为有效地址。针对上面那个报文，instructions的类型是apply_actions，因此经过函数decode_openflow11_instructions会把数组下标为OVSINST_OFPIT11_APPLY_ACTIONS的值修改为有效地址（即上图中红色字体）。

现在我们来看一下这个函数代码，下面红色字体就是那6种action：

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
enumofperr
ofpacts_pull_openflow_instructions(structofpbuf*openflow,
                                   unsignedintinstructions_len,
                                   enumofp_versionversion,
                                   structofpbuf*ofpacts)
{
conststructofp11_instruction*instructions;
/* 通过查看宏定义可知, N_OVS_INSTRUCTIONS=6 */
    conststructofp11_instruction*insts[N_OVS_INSTRUCTIONS];
    enumofperrerror;
 
    ofpbuf_clear(ofpacts);/* 清空缓冲区输出参数保留action */
 
    if(instructions_len%OFP11_INSTRUCTION_ALIGN!=0){
        VLOG_WARN_RL(&rl,"OpenFlow message instructions length %u is not a "
                     "multiple of %d",
                     instructions_len,OFP11_INSTRUCTION_ALIGN);
        error=OFPERR_OFPBIC_BAD_LEN;
        gotoexit;
    }
    /* 移除instructions_len大小内存数据instructions 保存数据起始位置*/
    instructions=ofpbuf_try_pull(openflow,instructions_len);
    if(instructions==NULL){
        VLOG_WARN_RL(&rl,"OpenFlow message instructions length %u exceeds "
                     "remaining message length (%"PRIu32")",
                     instructions_len,ofpbuf_size(openflow));
        error=OFPERR_OFPBIC_BAD_LEN;
        gotoexit;
    }
 
    /*
     * 解析openflow中instructions，并保存在指针数组out中
     * 这个函数介绍重点。我们放到后面进行详细解说！！
     * 这里说一下insts这个指针数组，即每个数组元素都是一个指针，指针类型就是
* 标准instruction头部，其大小固定是6。这里insts就是上面表格，经过这个函数
* 处理之后就会把某一个数组单元设置成有效地址。
     */
    error=decode_openflow11_instructions(
        instructions,instructions_len/OFP11_INSTRUCTION_ALIGN,
        insts);
    if(error){
        gotoexit;
    }
 
    /*
     * 针对上面的解析结构即对out指针数组进行action解析
     * 解析meter表
     */
    if(insts[OVSINST_OFPIT13_METER]){…
    }
 
    /*
     * 应用action--解析，当前flowmod就这个！着重说一下这个，
*其他无关代码已经删除
     */
    if(insts[OVSINST_OFPIT11_APPLY_ACTIONS]){
        constunionofp_action*actions;
        size_tmax_actions;
        /*
         * 可以有多个action
         * actions变量保存报文actions指针，这是一个联合结构。
         * max_actions变量保存action个数
         */
        get_actions_from_instruction(insts[OVSINST_OFPIT11_APPLY_ACTIONS],
                                     &actions,&max_actions);
 
        /*
         * 解析action 保存在ofpacts
         * 通过不同类型判断，是openflow1.0还是openflow1.1。对于上面报文来说，
* 最终调用解析函数是openflow1.1的函数即ofpact_from_openflow11。
* 注：actions这个变量时一个联合，这个地方涉及非常巧妙。
         */
        error=ofpacts_from_openflow(actions,max_actions,version,ofpacts);
        if(error){
            gotoexit;
        }
    }
 
    /*
     * 清空action--解析
     */
    if(insts[OVSINST_OFPIT11_CLEAR_ACTIONS]){…
    }
 
    /*
     * 重写action--解析
     */   
    if(insts[OVSINST_OFPIT11_WRITE_ACTIONS]){…
    }
 
    /*
     * 重写元数据--解析
     */   
    if(insts[OVSINST_OFPIT11_WRITE_METADATA]){…
    }
 
    /*
     * 跳转流表--解析
     */   
    if(insts[OVSINST_OFPIT11_GOTO_TABLE]){…
    }
 
    error=ofpacts_verify(ofpbuf_data(ofpacts),ofpbuf_size(ofpacts));
exit:
    if(error){
        ofpbuf_clear(ofpacts);
    }
    returnerror;
}

我们现在来分析一下这两个函数：decode_openflow11_instructions（解析instructions函数）和ofpacts_from_openflow（解析actions函数）。

函数decode_openflow11_instructions主要是循环遍历，不断解析instructions，内部最终处理函数是decode_openflow11_instruction，对于这个函数，比较难看懂，主要是因为里面switch-case子句是通过宏定义的，这样不便于理解。然而我们可以借助编译器（GCC），让它帮我们展开宏定义。由于展开后代码变得非常庞大，因此我只相关代码展示出来：

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
static enum ofperr
decode_openflow11_instruction(const struct ofp11_instruction *inst,
                              enum ovs_instruction_type *type)
{
    uint16_t len = ntohs(inst->len);
 
    switch (inst->type) {
    case CONSTANT_HTONS(OFPIT11_EXPERIMENTER):
        return OFPERR_OFPBIC_BAD_EXPERIMENTER;
    /* 该报文相关的case子句—apply_actions */
    case CONSTANT_HTONS( OFPIT11_APPLY_ACTIONS ):
    if ( true ? len >= sizeof(struct ofp11_instruction_actions) : len == sizeof(struct ofp11_instruction_actions) )
    {
        *type = OVSINST_OFPIT11_APPLY_ACTIONS;/* 返回枚举定义*/
        return(0);
    } 
    else
    {
        return(OFPERR_OFPBIC_BAD_LEN);
    }
 
default:
        return OFPERR_OFPBIC_UNKNOWN_INST;
    }
}

我们再来看一下actions解析函数，上面已经说过了，对于openflow1.3的actions报文，最终会进入这个ofpact_from_openflow11函数，函数主体代码如下：

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
staticenumofperr
ofpact_from_openflow11(constunionofp_action*a,enumofp_versionversion,
                       structofpbuf*out)
{
    enumofputil_action_codecode;
    enumofperrerror;
    structofpact_vlan_vid*vlan_vid;
    structofpact_vlan_pcp*vlan_pcp;
 
    error=decode_openflow11_action(a,&code);/* 这个函数和上面那个函数类似，也是通过宏定义构建的，也可以通过同样方式获取宏展开后代码。 */
    if(error){
        returnerror;
    }
 
    /*
     * openflow1.2+ 中部分消息将废弃掉
     */
    if(version>=OFP12_VERSION){
        …
        }
    }
 
    switch(code){
    caseOFPUTIL_ACTION_INVALID:
#define OFPAT10_ACTION(ENUM, STRUCT, NAME) case OFPUTIL_##ENUM:
#define OFPAT13_ACTION(ENUM, STRUCT, EXTENSIBLE, NAME) case OFPUTIL_##ENUM:
#include "ofp-util.def"
        OVS_NOT_REACHED();
 
    caseOFPUTIL_OFPAT11_OUTPUT:/* 针对上面报来说，最终会进入这个case子句 */
        returnoutput_from_openflow11(&a->ofp11_output,out);/* 将ofp11_output中端口信息在保存out中。 */
…
}//end switch 函数结束
}
 
staticenumofperr
output_from_openflow11(conststructofp11_action_output*oao,
                       structofpbuf*out)
{
    structofpact_output*output;
    enumofperrerror;
/* 这个函数是宏定义函数，最终调用是调用ofpact_put。宏定义位置：ofp_actions.h，689行 */
    output=ofpact_put_OUTPUT(out);
    output->max_len=ntohs(oao->max_len);
 
    error=ofputil_port_from_ofp11(oao->port,&output->port);/* 将端口保存在output->port中。 */
    if(error){
        returnerror;
    }
 
    returnofpact_check_output_port(output->port,OFPP_MAX);/* 验证端口 */
}
flow mod操作主要是有五类操作，增加、修改、严格修改、删除、严格删除。代码如下，对于上面报文是添加操作：
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
static enum ofperr
handle_flow_mod__(struct ofproto *ofproto, struct ofconn *ofconn,
                  struct ofputil_flow_mod *fm, const struct ofp_header *oh)
    OVS_EXCLUDED(ofproto_mutex)
{
    enum ofperr error;
 
    ovs_mutex_lock(&ofproto_mutex);
    if (ofproto->n_pending < 50) {
        switch (fm->command) {
        case OFPFC_ADD:
            error = add_flow(ofproto, ofconn, fm, oh); /* 将上面解析出来match、instructions保存到ofproto的flow中 */
            break;
        case OFPFC_MODIFY:
            …
        case OFPFC_MODIFY_STRICT:
            …
        case OFPFC_DELETE:
            …
        case OFPFC_DELETE_STRICT:
            …
        default:
            …
        }
    } else {
        ovs_assert(!list_is_empty(&ofproto->pending));
        error = OFPROTO_POSTPONE;
    }
    ovs_mutex_unlock(&ofproto_mutex);
 
/* 执行rule。此函数比较简单，通过函数指针，进行下发到datapath。
* 主要通过netlink协议。
 */
    run_rule_executes(ofproto);
    return error;
}
我们现在来看一下add_flow这个函数，这个函数比较大，需要我们耐心分析。这个函数主要是对解析成功match、instructions再次进行抽象，抽象成openvswitch中rule。
虽然add_flow这个函数比较长，但是函数逻辑还是比较清晰：如果已经存在rule则进行修改操作，否则创建（这个是openflow标准）。针对我们这个flow_mod，显然是创建，所以只需要关心创建流程即可，其他流程可以以后再进行详细分析。
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
staticenumofperr
add_flow(structofproto*ofproto,structofconn*ofconn,
         structofputil_flow_mod*fm,conststructofp_header*request)
    OVS_REQUIRES(ofproto_mutex)
{
    structoftable*table;
    structcls_rulecr;
    structrule*rule;
    uint8_ttable_id;
    interror=0;
 
    if(!check_table_id(ofproto,fm->table_id)){
        error=OFPERR_OFPBRC_BAD_TABLE_ID;
        returnerror;
    }
 
    /* Pick table. */
    if(fm->table_id==0xff){
        //不关心，报文中table_id是0
    }elseif(fm->table_id<ofproto->n_tables){
        table_id=fm->table_id;/* 设置table_id，用于保存rule */
    }else{
        returnOFPERR_OFPBRC_BAD_TABLE_ID;
    }
   
    /* 选择table对象 */
    table=&ofproto->tables[table_id];
 
    /* 校验是否有权限例如:只读 */
    if(!oftable_is_modifiable(table,fm->flags)){
        returnOFPERR_OFPBRC_EPERM;
    }
 
    if(!(fm->flags&OFPUTIL_FF_HIDDEN_FIELDS)){/* 如果没有设置这个标志位则进入if分支 */
        if(!match_has_default_hidden_fields(&fm->match)){
            VLOG_WARN_RL(&rl,"%s: (add_flow) only internal flows can set "
                         "non-default values to hidden fields",ofproto->name);
            returnOFPERR_OFPBRC_EPERM;
        }
}
以上这些操作，对于我们分析代码流程不是很关键，我们只需要知道，通过报文中的table_id字段，能够获取OpenvSwitch中定义的table对象即可，其他内容无需深入研究。下面这部分代码，主要是用于修改操作，即如果存在rule则进行修改，修改完成后直接退出函数。
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
/* 规则分类器初始化 */
    cls_rule_init(&cr, &fm->match, fm->priority);
 
    /* Transform "add" into "modify" if there's an existing identical flow.
     * 如果flow存在则add动作变成修改动作对于rule操作必须是线程安全的
     * 对于第一次添加，下面通过查找，返回的rule肯定是null
     * classifier_find_rule_exactly严格查找
     */
    fat_rwlock_rdlock(&table->cls.rwlock);
    rule = rule_from_cls_rule(classifier_find_rule_exactly(&table->cls, &cr));/* 查找操作，如果存在返回rule对象，反之为null。*/
    fat_rwlock_unlock(&table->cls.rwlock);
   
    if (rule) { /* flow存在则进行修改操作 */
        cls_rule_destroy(&cr);
        if (!rule_is_modifiable(rule, fm->flags)) {
            return OFPERR_OFPBRC_EPERM;
        } else if (rule->pending) {
            return OFPROTO_POSTPONE;
        } else {
            struct rule_collection rules;
 
            rule_collection_init(&rules);
            rule_collection_add(&rules, rule);
            fm->modify_cookie = true;
            error = modify_flows__(ofproto, ofconn, fm, request, &rules);/* 修改*/
            rule_collection_destroy(&rules);
            return error;
        }
    }
针对我们的报文来说，肯定是不存在rule，所以不会进入这个修改分支。因此不进行深入分析，而且修改操作是基于添加后进行，所以个人认为，如果把添加流程搞清楚后，修改操作也会非常简单。
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
/* Serialize against pending deletion. */
    if(is_flow_deletion_pending(ofproto,&cr,table_id)){
       // 不关心
    }
 
    /* Check for overlap, if requested. 检查rule是否重叠 */
    if(fm->flags&OFPUTIL_FF_CHECK_OVERLAP){
        //不关心
    }
 
    /* 每个table包的rule是有限。取决于变量table->max_flows,默认UINT_MAX(即最大)
     * 如果现有rule数量，已经达到最大，则需要删除一些rule，以保证能够把新rule
     * 插入到table中。
     */
    error=evict_rules_from_table(ofproto,table,1);
    if(error){
        cls_rule_destroy(&cr);
        returnerror;
    }
 
    /* Allocate new rule.
     * ofproto_class 指向 ofproto_dpif_class。最终调用的函数是rule_alloc
     */
    rule=ofproto->ofproto_class->rule_alloc();
    if(!rule){
        cls_rule_destroy(&cr);
        VLOG_WARN_RL(&rl,"%s: failed to allocate a rule.",ofproto->name);
        returnENOMEM;
    }
 
    /* Initialize base state. 初始化一些基本数据*/
    *CONST_CAST(structofproto**,&rule->ofproto)=ofproto;
    cls_rule_move(CONST_CAST(structcls_rule*,&rule->cr),&cr);
    ovs_refcount_init(&rule->ref_count);
    rule->pending=NULL;
    rule->flow_cookie=fm->new_cookie;
    rule->created=rule->modified=time_msec();
 
    ovs_mutex_init(&rule->mutex);
    ovs_mutex_lock(&rule->mutex);
    rule->idle_timeout=fm->idle_timeout;
    rule->hard_timeout=fm->hard_timeout;
    ovs_mutex_unlock(&rule->mutex);
 
    *CONST_CAST(uint8_t*,&rule->table_id)=table-ofproto->tables;
    rule->flags=fm->flags&OFPUTIL_FF_STATE;
    ovsrcu_set(&rule->actions,
               rule_actions_create(ofproto,fm->ofpacts,fm->ofpacts_len));
    list_init(&rule->meter_list_node);
    rule->eviction_group=NULL;
    list_init(&rule->expirable);
    rule->monitor_flags=0;
    rule->add_seqno=0;
    rule->modify_seqno=0;
 
    /* Construct rule, initializing derived state.
     * ofproto_class 指向 ofproto_dpif_class。最终调用函数是rule_construct
     * 主要初始化rule的成员变量
     */
    error=ofproto->ofproto_class->rule_construct(rule);
    if(error){
        ofproto_rule_destroy__(rule);
        returnerror;
    }
 
    /* 当上面完成操作后，则将rule插入到table中。*/
    do_add_flow(ofproto,ofconn,request,fm->buffer_id,rule);
    returnerror;
}
通过上面的分析，已经完成对fm进一步抽象，现在我们回到函数handle_flow_mod__，看一下此rule执行操作，即下发到datapath。我们知道用户态vswitchd和内核态datapath是通过netlink进行通信，我们在函数run_rule_executes中，将会看到netlink应用。
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
static void
run_rule_executes(struct ofproto *ofproto)
    OVS_EXCLUDED(ofproto_mutex)
{
    struct rule_execute *e, *next;
    struct list executes;
 
    /* 链表迁移 */
    guarded_list_pop_all(&ofproto->rule_executes, &executes);
 
    /* 遍历链表 */
    LIST_FOR_EACH_SAFE (e, next, list_node, &executes) {
        struct flow flow;
 
        /* 从packet中提取flow */
        flow_extract(e->packet, NULL, &flow);
        flow.in_port.ofp_port = e->in_port;
        ofproto->ofproto_class->rule_execute(e->rule, &flow, e->packet);
                   rule_execute_destroy(e);
    }
}
通过上面代码可知，最终调用函数是rule_execute，函数调用关系如下：

这些函数就不分析了，主要原因是我对netlink不熟悉，而且我们的目的是，知道是什么样的流程下发到datapath即可。
上面有一个函数我们分析，这里单独分析一下：do_add_flow。这个插入rule的流程比较繁琐，主要原因是规则很多。这里函数里面会调用到函数oftable_insert_rule，
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
staticvoid
oftable_insert_rule(structrule*rule)
    OVS_REQUIRES(ofproto_mutex)
{
    structofproto*ofproto=rule->ofproto;
    structoftable*table=&ofproto->tables[rule->table_id];
    conststructrule_actions*actions;
    boolmay_expire;
 
    ovs_mutex_lock(&rule->mutex);
    may_expire=rule->hard_timeout||rule->idle_timeout;
    ovs_mutex_unlock(&rule->mutex);
/*
* 插入规则1：如果存在定时器，则将rule插入到定时器链表中
*/
    if(may_expire){
        list_insert(&ofproto->expirable,&rule->expirable);
    }
/*
     * 插入规则2：根据cookie值，插入hmap中。
     */
    cookies_insert(ofproto,rule);
/*
* 插入规则3 ：根据meter id值，插入链表中。
*/
    actions=rule_get_actions(rule);
    if(actions->provider_meter_id!=UINT32_MAX){
        uint32_tmeter_id=ofpacts_get_meter(actions->ofpacts,
                                              actions->ofpacts_len);
        structmeter*meter=ofproto->meters[meter_id];
        list_insert(&meter->rules,&rule->meter_list_node);
}
 
/*
* 插入规则4：插入分类器中的subtable。
* 这个函数是重点内容，因此在修改的时候也会处理subtable。
*/
    fat_rwlock_wrlock(&table->cls.rwlock);
    classifier_insert(&table->cls,CONST_CAST(structcls_rule*,&rule->cr));
fat_rwlock_unlock(&table->cls.rwlock);
 
/*
* 插入规则5：插入到eviction_group中。
*/
    eviction_group_add_rule(rule);
}
其实对于上面这多插入规则，只能从代码中理解表面意思，至于为什么这样做，还不是很理解。从文章篇幅可知，flow_mod这个消息是最复杂的消息，这里写的只是个人观点，有些地方可能理解不到位或者描述不到位，希望读者能够指点出来，以便进行修改。今天突然下载了github中最新代码，发现很多函数都没有了，所以这里指出，文章分析的函数是以ovs-2.3.2版本为准。终于结束，写这篇博客断断续续用了一周的时间，希望能够帮助大家理解。
作者简介：
徐小冰：毕业于河北大学，主要从事嵌入式软件开发，虚拟化，SDN。目前基于ODL和Open vSwitch进行二次开发，希望与广大网友一起探讨学习。作者系OpenDaylihgt群（194240432）资深活跃用户，@IT难人。

声明：本文明来自 SDNLAB

0 0