openVswitch 2.10.0 (OVS)源码分析 Vswitchd启动(上)

Vswitchd是ovs中运行在用户空间的守护进程, 实现ovs主要的功能逻辑, 本文将着重分析其启动过程.

数据结构

bridge/port/iface/ofproto/ofport

在数通领域, 交换机和桥很多时候可以是在说一个东西, 它工作在二层, 可以添加多个端口, 从一个端口上收到的报文会根据MAC表从其他某个端口转发出去. 在ovs中, 它也还是一个东西, 不过ovs用两个数据结构描述它们: 交换机(ofproto)与桥(bridge). 它们在ovs中是一一对应的, 也就是说一个bridge就有一个对应的ofproto. 相比而言, bridge更贴近用户, ofproto跟底层联系更多. 想想添加一个桥的命令是 ovs-vsctl add-br 就可见一斑了.
交换机需要添加端口才能具有实际作用, ovs用port和ofprot描述端口, 前者对应bridge, 更贴近用户配置, 而后者对应ofproto,更贴近底层. ovs还有一个结构叫iface, 一般而言, 一个port包含一个iface, 但存在一种聚合(bond)的情况, 我们可以把多个iface捆在一起, 将它们一并归纳到一个port.此时port和iface就是一对多的关系了.

以下为前面提到的几个数据结构之间的联系

Vswitchd启动

入口

Vswitchd 进程的入口在ovs-vswitchd.c ,下面我们将主要关注主干流程的分析,而忽略其中的一些旁枝末节

int main(int argc, char *argv[])
{
     remote = parse_options(argc, argv, &unixctl_path)
     bridge_init(remote);
     while (!existing){
           bridge_run();     
           bridge_wait();
           poll_block();
     }
     .....exit();
     return 0;
}

初始化 bridge 模块

bridge 模块的初始化在 bridge_init 中完成, bridge_init主要的动作是连接数据库ovsdb, 并从中读取配置信息.

void bridge_init(const char *remote)
{
    idl = ovsdb_idl_create(remote, &ovsrec_idl_class, true, true);
 
    ovsdb_idl_omit_alert(idl, &ovsrec_open_vswitch_col_cur_cfg);
    ......
}

注意, 像ovsrec_open_vswitch_col_cur_cfg这样的全局变量的定义是编译时自动生成的, 从官方下载的代码中最初是没有它的定义的.

运行 bridge 模块

bridge 模块的初始化在 bridge_run 中进行

void bridge_run(void)
{
    cfg = ovsrec_open_vswitch_first(idl);
    bridge_init_ofproto(cfg);
    bridge_run__();
    if (ovsdb_idl_get_seqno(idl) != idl_seqno || if_notifier_changed(ifnotifier))
    {
        bridge_reconfigure(cfg ? cfg : &null_cfg)
    }
    ...
}

首先读取数据库ovsdb中的配置到cfg, 此时, cfg中就有了诸如用户创建了多少个bridge, 每个bridge中有多少个port, iface等信息.

在bridge_init_ofproto中, 会进行ofproto library初始化, 之前提到了, bridge更靠近用户配置, ofproto更靠近底层, 这里就是进行底层库的初始化

void ofproto_init(const struct shash *iface_hints)
{
    ofproto_class_register(&ofproto_dpif_class);
    .....
    for (i = 0; i < n_ofproto_classes; i++) {
        ofproto_classes[i]->init(&init_ofp_ports);
    }
}

ofproto library首先进行ofproto class类的注册, ovs当前仅支持一种类, 即ofproto_dpif_class, 所以后面调用init, 实际上也只会调用ofproto_dpif_class->init().
观察ofproto的数据结构中 的前几项

struct ofproto{
   const struct ofproto_class *ofproto_class;
   char *type;             /* Datapath type */ 
   char *name;             /* Datapath name */
   ...
}

其中, ofproto_class即为生产者的class, 在当前ovs中, 只会指向ofproto_dpif_class, type为ofproto的类型, 也可称为provider, 当前的ofproto_dpif_class有两种provider , 记录在dpif_classes中, 它的来源是base_dpif_classes[]

static const struct dpif_class *base_dpif_classes[] = {
  &dpif_netlink_class,
  &dpif_netdev_class,
} 

可以把dpif_classes看成一张注册表, 里面有两个条目

ofproto_dpif_class实现的enumerate_types方法可以列举当前支持的datapath的类型, 在当前的ovs实现中,就是"system"和"netdev"

再来看 bridge_run__(void)

static void bridge_run__(void)
{
    ofproto_enumerate_types(&types);
    SSET_FOR_EACH(type, &types){
        ofproto_type_run(type);
    }
    HMAP_FOR_EACH(br, node, &all_bridges){
       ofproto_run(br->ofproto);
    }
}

首先bridge_run__将当前支持的type列举出来, 再逐个调用ofproto_type_run ,最终调用到ofproto_dpif_class->type_run(),这里在第一次运行时, 由于all_dpif_backers为空,所以就直接返回了.
然后, bridge_run__对all_bridges上记录的每个bridge调用ofproto_run, 同样在第一次运行在这里时all_bridges为空, 所以也不会有实际的动作.