OVS vswitchd啟動（三十七）

vswitchd是ovs中執行在使用者空間的守護程序, 實現ovs主要的功能邏輯, 本文將著重分析其啟動過程。

在數通領域, 交換機和橋很多時候可以是在說乙個東西, 它工作在二層, 可以新增多個埠, 從乙個埠上收到的報文會根據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 程序的入口在ovs-vswitchd.c ,下面我們將主要關注主幹流程的分析,而忽略其中的一些旁枝末節

int
main
(int argc,
char
*ar**)
....
.exit()
;return0;
}

bridge 模組的初始化在 bridge_init 中完成, bridge_init主要的動作是連線資料庫ovsdb, 並從中讀取配置資訊.

void
bridge_init
(const
char
*remote)

bridge 模組的初始化在 bridge_run 中進行

void
bridge_run
(void)...}

首先讀取資料庫ovsdb中的配置到cfg, 此時, cfg中就有了諸如使用者建立了多少個bridge, 每個bridge中有多少個port, iface等資訊.

在bridge_init_ofproto中, 會進行ofproto library初始化, 之前提到了, bridge更靠近使用者配置, ofproto更靠近底層, 這裡就是進行底層庫的初始化

void
ofproto_init
(const
struct shash *iface_hints)
}

ofproto library首先進行ofproto class類的註冊, ovs當前僅支援一種類, 即ofproto_dpif_class, 所以後面呼叫init, 實際上也只會呼叫ofproto_dpif_class->init().

觀察ofproto的資料結構中的前幾項

struct ofproto

其中, 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_classes看成一張登錄檔, 裡面有兩個條目

ofproto_dpif_class實現的enumerate_types方法可以列舉當前支援的datapath的型別, 在當前的ovs實現中,是"system"和"netdev"

再來看 bridge_run__(void)

static
void
bridge_run__
(void
)hmap_for_each
(br, node,
&all_bridges)
}

首先bridge_run__將當前支援的type列舉出來, 再逐個呼叫ofproto_type_run ,最終呼叫到ofproto_dpif_class->type_run(),這裡在第一次執行時, 由於all_dpif_backers為空,所以就直接返回了.

然後, bridge_run__對all_bridges上記錄的每個bridge呼叫ofproto_run, 同樣在第一次執行在這裡時all_bridges為空, 所以也不會有實際的動作.

OVS vswitchd啟動（三十七）

OVS vswitchd啟動（三十五）

學習筆記（三十）

每日程式設計（三十）

OVS vswitchd啟動（三十七）

OVS vswitchd啟動（三十五）

學習筆記（三十）

每日程式設計 （三十）

相關推薦

每日程式設計（三十）