異數OS 2017 DPDK 峰會觀後感
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
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
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的丟棄包袱完全開創新世界）。