https://zhuanlan.zhihu.com/p/57870521
本文首發SDNLAB。
現代的虛擬化技術使得開發和部署高級網絡服務變得更加簡單方便。基於虛擬化的網絡服務，具有多樣性，低成本，易集成，易管理，低持有成本等優點。而虛擬交換機已經成為了一個高度虛擬化環境不可缺少的一部分。OpenVSwitch是所有虛機交換機中的佼佼者，廣泛被各種SDN方案采用。
OpenVSwitch kernel datapath
--
OpenVSwitch是一個實現了OpenFlow的虛擬交換機，它由多個模塊組成。主要有位於用戶空間的ovsdb-server和ovs-vswitchd進程，和位於內核空間的OVS datapath組成。在一個SDN架構中，Controller將各種網絡拓撲，網絡功能轉換成OVS的數據和OpenFlow規則，分別下發給ovsdb-server和ovs-vswitchd進程，OpenFlow規則可以通過ovs-ofctl dump-flows查看。
網絡數據的轉發，都是由位於內核空間的OVS datapath完成。用戶空間和內核空間的信息是怎么同步的？對於一個網絡數據流，第一個數據包到達OVS datapath，這個時候的datapath沒有轉發信息，並不知道怎么完成轉發。接下來OVS datapath會查詢位於用戶空間的ovs-vswitchd進程。ovs-vswitchd進程因為有OpenFlow信息，可以根據OpenFlow規則完成match-action操作，也就是從一堆OpenFlow規則里面匹配網絡數據包對應的規則，根據這些規則里的action實現轉發。
這樣第一個數據包就完成了轉發。與此同時，ovs-vswitchd會通過netlink向OVS datapath寫入一條（也有可能是多條）轉發規則，這里的規則不同於OpenFlow規則，可以通過ovs-dpctl dump-flows查看。這樣，同一個網絡數據流的后繼網絡數據包到達OVS datapath時，因為已經有了轉發規則，datapath就可以直接完成轉發，不再需要向ovs-vswitchd查詢。
通過ovs-vswitchd查找OpenFlow實現轉發的路徑稱為slow-path，通過OVS datapath直接轉發的路徑稱為fast-path。OVS的設計思路就是通過slow-path和fast-path的配合使用，完成網絡數據的高效轉發。這種設計思想類似於傳統的硬件網絡設備。(經sdnlab的讀者提示，這里其實更像fast switching，在此感謝)例如Cisco CEF架構，也是分成了兩層，Control Plane存儲了當前設備的全部轉發信息（RIB），而Data Plane會存儲實際的轉發信息（FIB）。網絡數據的轉發在Data Plane完成，當Data Plane沒有相應的FIB，會向上查詢RIB進而構建FIB。
OpenVSwitch kernel datapath，實際上是在通用的硬件&軟件上實現了專用網絡設備的功能。優點在最開始說過了，但是這種實現也有自己的缺點。
硬件交換機因為有專門的轉發硬件，可以保證任意時間都有一定的資源用於轉發。但是OVS datapath在操作系統內核空間實現轉發，本質上是通過操作系統內的幾個進程來完成工作。操作系統會像對待其他進程一樣，將CPU的部分時間片，而不是整個CPU分配給虛擬交換機，內存也需要受操作系統的管理，這就存在資源搶占的可能。所以，虛擬交換機並不能保證在需要轉發網絡數據的時候一定占有資源。
另一方面，因為操作系統本身的設計，需要經過硬中斷，軟中斷，內核空間和用戶空間的切換來完成網絡數據的傳輸，通過內核進行轉發使得網絡數據在操作系統內的路徑也很長。
所以現在的共識是，基於內核實現的虛擬交換機，會對網絡性能（throughput，latency，PPS等）帶來額外的損耗。這是虛擬交換機不可回避的問題。OVS kernel datapath多用於一些對網絡性能要求不高的場合。
OpenVSwitch DPDK
--
DPDK（Data Plane Development Kit）本身是個獨立的技術，OpenVSwitch在2012年提供了對DPDK的支持。
DPDK的思路是，繞過操作系統內核，在用戶空間，通過PMD（Poll Mode Driver）直接操作網卡的接收和發送隊列。在網絡數據的接收端，PMD會不斷的輪詢網卡，從網卡上收到數據包之后，會直接通過DMA將其傳輸到預分配的內存中，同時更新接收隊列的指針，這樣應用程序很快就能感知收到數據包。DPDK繞過了大部分中斷處理和操作系統的內核空間，大大縮短了網絡數據在操作系統內的路徑長度。
另一方面，因為PMD采用了輪詢的方式與網卡交互，DPDK要獨占部分CPU和內存，這樣在任意時間都有一定的資源用於網絡轉發，避免了因為操作系統調度帶來的資源搶占的問題。
因為DPDK繞過了內核空間，OVS-DPDK的datapath也存在於用戶空間，采用如下圖所示。對於SDN controller來說，因為連接的是ovs-vswitchd和ovsdb-server，所以感覺不到差異。
DPDK針對主機網絡虛擬化的問題，提出了有效的解決方案。基於DPDK的網絡方案，能大幅提升網絡性能，並且已經在一些對網絡性能有要求的場合使用，例如NFV。
不過，雖然DPDK在一定程度上解決了性能的問題，並且DPDK社區在不斷的進行優化，但是DPDK也有其自身的問題。首先，DPDK沒有集成在操作系統中，使用DPDK就需要額外的安裝軟件，這增加了維護成本。其次，繞過了Linux內核空間，也就是繞過了網絡協議棧，這使得基於DPDK的應用更難調試和優化，因為大量的基於Linux kernel網絡調試監控工具在DPDK下不可用了。第三個問題，DPDK獨占了部分CPU和內存，這實際上分走了本該用來運行應用程序的資源，最直觀的感受是，使用了DPDK之后，主機可以部署的虛機數變少了。
OpenVSwitch Hardware offload
--
OpenVSwitch硬件卸載是近幾年才提出的方案，到目前為止並不完全成熟。
Linux TC（Traffic Control）Flower
--
要介紹OVS硬件卸載，必須要從TC說起。TC在Linux Kernel 2.2版本開始提出，並在2.4版本（2001年）完成。最初的Linux TC是為了實現QoS[1]，當然TC現在仍然有QoS的功能。它在netdev設備的入方向和出方向增加了掛載點，進而控制網絡流量的速度，延時，優先級等。Linux TC在整個Linux Kernel Datapath中的位置如下圖所示：
隨后，TC增加了Classifier-Action子系統[2]，可以根據網絡數據包的報頭識別報文，並執行相應的Action。與其他的Classifier-Action系統，例如OpenFlow，不一樣的是，TC的CA子系統並不只是提供了一種Classifier（識別器），而是提供了一個插件系統，可以接入任意的Classifier，甚至可以是用戶自己定義的Classifier。
在2015年，TC的Classifier-Action子系統增加了對OpenFlow的支持[3]，所有的OpenFlow規則都可以映射成TC規則。隨后不久，OpenFlow Classifier又被改名為Flower Classifier。這就是TC Flower的來源。
Linux TC Flower hardware offload
--
在2011年，Linux內核增加了基於硬件QoS的支持[4]。因為TC就是Linux內實現QoS的模塊，也就是說Linux增加了TC的硬件卸載功能。在2016年，Linux內核又增加了對TC Classifier硬件卸載的支持，但是這個時候只支持了u32類型的Classifier（與TC Flower並列的，但是歷史更悠久的一種Classifier）。在4.9~4.14內核，Linux終於增加了對TC Flower硬件卸載的支持。也就是說OpenFlow規則有可能通過TC Flower的硬件卸載能力，在硬件（主要是網卡）中完成轉發。
TC Flower硬件卸載的工作原理比較簡單。當一條TC Flower規則被添加時，Linux TC會檢查這條規則的掛載網卡是否支持並打開了NETIF_F_HW_TC標志位，並且是否實現了ndo_steup_tc（TC硬件卸載的掛載點）。如果都滿足的話，這條TC Flower規則會傳給網卡的ndo_steup_tc函數，進而下載到網卡內部[5]。
網卡的NETIF_F_HW_TC標志位可以通過ethtool來控制打開關閉：
# ethtool -K eth0 hw-tc-offload on
# ethtool -K eth0 hw-tc-offload off
同時，每條規則也可以通過標志位來控制是否進行硬件卸載。相應的標志位包括以下：
- TCA_CLS_FLAGS_SKIP_HW：只在軟件（系統內核TC模塊）添加規則，不在硬件添加。如果規則不能添加則報錯。
- TCA_CLS_FLAGS_SKIP_SW：只在硬件（規則掛載的網卡）添加規則，不在軟件添加。如果規則不能添加則報錯。
- 默認（不帶標志位）：嘗試同時在硬件和軟件下載規則，如果規則不能在軟件添加則報錯。
通過TC命令查看規則，如果規則已經卸載到硬件了，可以看到 in_hw標志位。
OVS-TC
--
OpenVSwitch在2018年增加了對TC Flower的支持，結合前面的描述，OVS的datapath現在有卸載到網卡的可能了。
前面說過，TC Flower規則現在可以下發到網卡上，相應的網卡上也會有一個虛機交換機。Mellanox稱這個虛擬交換機為eSwitch。OVS初始化的時候，會向eSwitch下發一條默認的規則，如果網絡包匹配不了任何其他規則，則會被這條默認規則匹配。這條規則的action就是將網絡數據包送到eSwitch的管理主機，也就是說送到了位於Linux kernel的datapath上。如果這個網絡數據包是首包的話，那根據前面的描述，在kernel的OVS datapath會繼續上送到位於用戶空間的ovs-vswitchd。因為ovs-vswitchd中有OpenFlow規則，ovs-vswitchd還是可以完成轉發。不一樣的地方是，ovs-vswitchd會判斷當前數據流對應的規則能否offload（卸載）到網卡。如果可以的話，ovs-vswitchd會調用通過TC接口將flow規則下發至硬件。這樣，同一個數據流的后繼報文，可以直接在網卡的eSwitch中完成轉發，根本不需要走到主機操作系統來。Datapath規則的aging（老化）也是由ovs-vswitchd輪詢，最終通過TC接口完成刪除。Datapath的變化如下所示。
在OVS-TC中，嚴格來說，現在Datapath有三個，一個是之前的OVS kernel datapath，一個是位於Kernel的TC datapath，另一個是位於網卡的TC datapath。位於kernel的TC datapath一般情況下都是空的，它只是ovs-vswitchd下發硬件TC Flower規則的一個掛載點。
使用OVS-TC方案，可以提供比DPDK更高的網絡性能。因為，首先網絡轉發的路徑根本不用進操作系統，因此變的更短了。其次，網卡，作為專用網絡設備，轉發性能一般要強於基於通用硬件模擬的DPDK。另一方面，網卡的TC Flower offload功能，是隨着網卡驅動支持的，在運維上成本遠遠小於DPDK。
但是OVS-TC方案也有自己的問題。首先，它需要特定網卡支持，不難想象的是，支持這個功能的網卡會更貴，這會導致成本上升，但是考慮到不使用DPDK之后釋放出來的CPU和內存資源，這方面的成本能稍微抵消。其次，OVS-TC功能還不完善，例如connection track功能還沒有很好的支持。第三，這個問題類似於DPDK，因為不經過Linux kernel，相應的一些工具也不可用了，這使得監控難度更大。
最后
--
本文介紹了OVS的三種datapath實現，並且着重描述了OVS-TC。三種實現中，OVS kernel最穩定，功能最全，相應的配套工具也最多，缺點就是性能較差，在對網絡性能沒有特殊要求的場合，OVS kernel還是首選；OVS DPDK能在一定程度上提升網絡性能，並且對硬件沒有依賴，但是需要占用主機的資源，並且需要有一定的維護成本；OVS-TC具有最好的網絡性能，但是目前不太成熟，並且依賴特定的網卡，不過個人認為這是一個比較好的發展方向。
參考
--
[1] http://tldp.org/HOWTO/Traffic-Control-HOWTO/overview.html#o-what-is
[2] https://people.netfilter.org/pablo/netdev0.1/papers/Linux-Traffic-Control-Classifier-Action-Subsystem-Architecture.pdf
[3] https://lwn.net/Articles/638585/
[4] https://lwn.net/Articles/420509/
[5] https://www.netdevconf.org/2.2/papers/horman-tcflower-talk.pdf
[6] https://netdevconf.org/1.2/papers/efraim-gerlitz-sriov-ovs-final.pdf