1.DPDK in Container

使用虛擬網卡設備技術為每一個容器分配一個IP 網卡適配器（queue）。容器技術可以解決虛擬機技術中虛擬機過于臃腫，難于熱遷移的問題，可能可以代替美團OVS方案，解決OVS熱遷移方案不足的問題。

2.F-Stack
F-Stack拒絕有意義的提問，帶來了現場的一番哄笑，F-Stack違背了DPDK最初的技術方向，其提供了POSIX接口被迫使用了Linux線程IO模型，導致其能力只能達到linux協議棧RSS 無鎖優化后的1.4倍，這是mtcp ans 也存在的同樣問題，而完全放棄Linux線程IO模型自己實現OS任務調度的seastar則是F-Stack mtcp ans 性能的5-10倍。


F-Stack拒絕了長連接性能，技術上講這主要是因為著名的C10K問題，在linux windows等主流操作系統中，在無法做QOS的情況下，大量長連接會很不穩定，導致雪崩問題，C10K問題不解決，則高效的消息推送方案則無法實施，比如未來的websocket技術，IM領域的360Push Whatsapp 環信等應用場合就無法做到，長連接性能直接關系到IM的運營成本，不知道微信是否有用F-Stack,具體可以參看Whatsapp “零”運營技術，而這一塊內容是異數OS方案需要解決的問題重點。


F-Stack演講者則用兩個現實問題搪塞了技術問題，說騰訊的業務都是短鏈接業務，騰訊的業務平臺都要使用linux生態，所以放棄了自研協議棧，這在技術上講實際是一種退步。


F-Stack在Send時多出現了一次內存拷貝動作，這個問題在異數OS中則被解決，原理是用異數OS的惰性IO資源，利用可用的ring buffer,在ring buffer可用的時候調度TCP worker線程在ring buffer上直接進行發包渲染工作。



3.A Better Virtio towords NFV Cloud
高科技，不懂：）


4.SPDK


沒詳細聽，感覺意義不是特別重大，因為應用系統中，磁盤IO壓力不會特別高，而且存儲是有壽命的，不宜頻繁使用，好的系統設計，比如一些kv都是盡量少的提交持久化磁盤任務，所以更好的文件系統以及更好的持久化任務系統（OS）才是真正的重點。


5.性能調優

for循環優化在內存io密集型應用方面用不上，只能用在多層for循環重壓力算法中，另外dpdk的內存預讀是否有用，我這邊使用的gcc的是沒有用的，不管是連續方寸還是隨機訪問。

問及Hash 隨機訪存優化，演講者就說去看vpp...要看的話就不要問了...

6. 美團OVS

美團OVS被人質問宿主機升級時，VM網卡斷了間隔怎樣處理，OVS本身并沒有解決方案，難以熱遷移，這其實是沒有直接解決方案的，而且僅僅是一個大類問題的一個小問題，本質問題是VM網卡斷了VM中的OS協議棧以及應用可能會面臨雪崩和應用宕機，這個問題也是異數OS方案解決的重點問題。




7.DPDL


聽的不太清楚，個人理解是RSS FDIR等技術并不能解決所有負載分流問題，所以需要誕生一種多核同時能處理一個ring的需求。因此原本的單生產者單消費者的ring需要被擴展設計出多生產者多消費者的ring,本來單生產者單消費者的ring是利用cache一致性協議無鎖無atom的多核通訊，cache line內不需要保序，但需求變更后則會要求加鎖保序。


提問者則有質疑，這樣的情況加鎖則意味著阻塞CPU核，最壞的自旋鎖情況則是多核比單核還慢。


提問者的質疑異數OS提供了解決方案。


異數OS的虛擬交換機使用無鎖無atom的多生產者多消費者的設計，用于LPC的實現，但必須配合異數OS使用，原理上講，他還是利用cache 一致性協議，沒有OS的情況，則只能自旋鎖阻塞CPU核，但是有OS則可以在try無效時做線程切換動作，在Linux下，這兩種鎖都被應用實做以便于適應不同的情況，原因是linux的線程切換代價極高，所以直接決定了鎖能夠達到的頻度，頻度不高時可以使用線程切換的自旋鎖，以便于充實CPU核，帶來性能提升，但網卡ring的PMD頻度很高，則不能用這種方式，而異數OS則可以用這個方案，原因是異數OS每盒最大線程切換能力可以達到50M。




8.intel 25Gbe Ethernet Adapter

個人理解，交換機領域功能不足，OS協議棧性能不濟的情況下，限制了其推廣。

9.DPDK Cryptodev Framework

提問者質疑延遲的問題，因為ring 要利用cache加速，不可能做大，因此延遲很敏感。

10.騰訊DDOS清洗

只講了使用DPDK抓包，清洗算法未知，做到了90M的速度，所以猜測只是一些DPI，fastpath,不能做復雜的session清洗。

所以提問者立刻問了能不能做5層6層7層清洗，集群黑名單同步等問題，顯然是無解的，所以現場再次哄笑。
DPDK社區群上有人懷疑騰訊來的人都是做技術運維的。




11.Low Latency Interrupt Mode PMD

回歸到了一個經典問題，DPDK只看到了自己的問題，沒發現別人玩不轉，DPDK說我用用戶層PMD繞開Linux內核協議棧，Linux說，沒我你做不出協議棧，這個問題又再次出現了，在局部上講，低流量壓力下時PMD浪費CPU資源，引入中斷模式的PMD可能會有效率，但是中斷關系到OS的線程切換，為了減少線程切換，一般要用綁核以及本地化任務調度等技術，但中斷顯然打破了上層設計格局。

提問者大概的意思是中斷速率和PMD速率是否可以自動根據網絡流量做自適應調節，但沒有得到直接答復，因為這可能超過了演講者的問題理解范圍。


異數OS則在這個問題上做了完整解決。
異數OS的PMD線程會被QOS做IOPS控制，在不同壓力下可以自適應變化到1M 2M....10M，在try miss的情況下PMD線程會被QOS掛起,切換到其他就緒線程（包括idle降溫線程），在IOPS資源可用時再被喚醒回來。


12.嵌入式交換機解決方案
交換機不是太懂:)

13.Panabit Support Millons Users in vBRAS

nat alg pppoe,聽到孫總200W 2000W session管理以及OS這一概念后，本來以為找到同行了，但提問希望關注他們的OS特性如何處理雪崩等問題時，則被轉移話題。


QQ技術群中 move經驗豐富 測試過他們的產品，說syn異常時，鏈接資源無法被清理，只能reboot,那么說明他們應該沒有OS來管理龐大的session 生命期，只是個fastpath，甚至連定時器都沒有（定時器在海量鏈接時很耗資源）。


孫總的銷售思路比研發在戰略上肯定更加清晰，導致論戰上的勝利。

如果有OS的話，有希望做應用業務級別精確的QOS,所以顛覆式創新比標準制定者（中興華為）肯定更能獲得希望，但他們的OS真做了嗎？

14. DPDK PMD in LXC
上場論戰太感人，在回味，所以沒聽。


15.Yuanshan DDOS清洗

降低的比騰訊要豐富些，但關鍵的清洗識別算法是保密的。
值得關注的是演講者講了一個冷笑話對全場主題做了一個有意義的總結，說一座山擋住wifi信號，然后愚公移山是否有意義來告誡參會者，每個人的理解可以不同，我的理解如下：


1. OVS等虛擬化等方案是否使問題變得更復雜，代價更高。
2. 標準制定者與顛覆式創新者之間，我們是否應該支持顛覆式創新者的做法（孫總的靈活QOS與中興華為移動的QOS標準，F-stack的被現實大山壓倒與seastar的丟棄包袱完全開創新世界）。

總結

以上是生活随笔為你收集整理的异数OS 2017 DPDK 峰会观后感的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。