處理upcall總體框架：
1.由函式
handle_upcalls（）批量處理（in batches）的是由核心傳上來的dpif_upcalls，會解析出upcall的型別。這裡主要看在核心中匹配流表失敗的miss_upcall。
處理完畢後會得到多個flow_miss。
結構體dpif_upcall代表的是由核心傳到使用者空間的乙個包，包含上傳原因，packet data。以及以netlink attr形式存在的鍵值。
struct
dpif_upcall ;
結構體flow_miss是將具有同樣流特徵的packets統一起來（ batching），效能可能會更優，所以這個結構體要將datapath inte***ce相關的資料佇列起來。每乙個flow_miss相應的是傳送的乙個或多個資料報，另外可能會在dpif中安裝流項。
struct
flow_miss
;2. 接下來。函式handle_miss_upcalls（）會依次遍歷這個flow_misses陣列，完畢的工作有：1）得到odp_key_fitness （也就是核心層/使用者層在流匹配上的一致程度）；2）從packet data中析取出流資訊miss->flow。3）然後對miss->flow進行雜湊。假設不存在則插入到to-do-list中。4）將這個upcall->packet插入到對應的節點上。
3.然後對於to-do-list中的每乙個元素，呼叫handle_flow_miss（）函式。它會從這個flow_miss中構造得到flow_miss_op，詳細的過程是：1）查詢ofproto的facet表ofproto->facets看針對這個flow的facet是否已存在。2）從ofproto的分類表中查詢與這個flow相應的分類規則，對於第乙個進入系統的包，還沒有建立起cls_rule。此時返回ofproto->miss_rule（
是怎樣初始化的呢？）；3）構造乙個facet，和當前的flow和rule_dpif關聯起來；4）這時候與flow_miss 匹配的facet也有了，接著呼叫函式 handle_flow_miss_with_facet（）可能會新增須要的操作到flow_miss_op中。詳細過程是：先是通過核心傳上來的key找subfacet是否存在，假設不存在就構建乙個；然後針對每乙個連線到這個flow_miss中的packet進行分別處理；handle_flow_miss_common（）會推斷假設rule->up.cr.priority = fail_open_priority的話就會傳送乙個packetin到sdn controller；對於剛建立的subfacet，其actions為空，所以函式subfacet_make_actions（）會依據subfacet中的rule來建立datapath action，儲存在odp_actions中。假設upcall的型別是dpif_uc_miss。就建立乙個dpif_op_flow_put型別的flow_miss_op（即dpif_flow_put），然後compose_slow_path（）會構建乙個使用者空間的user_action_cookie，它的型別是user_action_cookie_slow_path 表示這個流得到了使用者空間的處理。然後-> odp_put_userspace_action() 會新增乙個ovs_action_attr_userspace action到odp_actions中，屬性值包含netlink pid 和 剛才的cookie。
結構體facet是openflow flow的全然匹配（ exact-match）的例項抽象。它與"struct flow"關聯。代表ovs使用者空間對於exact match flow的觀點。有乙個或多個subfacet。每乙個subfacet追蹤著核心層datapath對於這個exact-match flow 的觀點。當核心層和使用者空間對乙個flow key觀點一致的時候，就僅僅有乙個subfacet（通常如此）。很多其它理解參考。
struct
facet ;
struct rule_dpif ;
/* an openflow flow within a "struct ofproto".
*
* with few exceptions, ofproto implementations may look at these fields but
* should not modify them. */
struct
rule;
struct
subfacet;
列舉體slow_path_reason列舉的是packet沒有在核心層被**的原因（也就是說這個packet是fast path）。
enum
slow_path_reason ;
列舉體subfacet_path列舉的是其可能的當前狀態：1）sf_not_installed表示沒有安裝在datapath中，這樣的情況出如今這個subfacet構建之後，銷毀之前，或者當我們在安裝乙個subfacet到datapath時出錯。由於subfacet中相應的有action，所以這裡的facet install指的是datapath執行了由使用者空間下發的詳細action。2）sf_fast_path說明相應的action已經得到了執行，packets能夠在核心層直接**；3）sf_slow_path是流規則指定了要發往使用者空間。
enum
subfacet_path ;
4. 通過上面的操作，flow_miss_op陣列就得到了。接下來呼叫函式 dpif_operate() 依次對dpif執行這些operation。
for (i = 0; i < n_ops; i++)
這裡就看flow put的情況，使用者空間會通過genl把對應的動作下發給核心datapath，而且接收響應。
OVS原始碼結構分析
下圖是ovs open vswitch 系統層面的邏輯圖。其中datapath是處於系統的核心層 kernel space 我們可以將datapath理解為乙個網橋 linux bridge 處於使用者態 user space 的主要是openvswitch client openflow clie...
轉錄組分析處理流程
1.fastqc 2.star build index star runthreadn 9 runmode genomegenerate genomedir data xx bio task le mir 03 2mirseq index genomefastafiles data xxbio ta...
ovs 資料報的處理過程
openvswitch的核心模組openvswitch.ko會在網絡卡上註冊乙個函式netdev frame hook，每當有網路包到達網絡卡的時候，這個函式就會被呼叫。static struct sk buff netdev frame hook struct sk buff skb 呼叫port...