文献阅读(一)
一
- 文章名稱:MACSAD: Multi-Architecture Compiler System for
Abstract Dataplanes (aka Partnering P4 with ODP) - 發表時間:2016-8
- 來源:SIGCOMM
- 針對什么問題?
- 把 P4 和 OpenDataPlane 結合在一起。在 MACSAD 下,P4 可以轉換為 ODP APIs 以實現平臺無關性,同時不用損失性能和硬件加速的選項。
- 所提出的架構有哪些實現難點?
- 無
- 貢獻有哪些?
- 展示了 MSCSAD 這樣一個高級模塊能夠支持新的領域專用語言和網絡平臺的多架構編譯系統。
- 設計了一個源到源的編譯器用于生成 P4 應用的中間文件。
- 執行了一個原型,在不同的平臺上使用兩個 P4 的例子來驗證可移植性。
- 測試了在 10G/s 速度下在不同數據平面和應用程序的的性能。
二
- 文章名稱:A Zero Flow Entry Expiration Timeout P4 Switch
- 發表時間:2018-5
- 來源:SOSR
- 針對什么問題?
- 為了支持大規模的 sdn 網絡,OpenFlow 交換機需要維護大量的流表項。然而流表是受限于 TCAM 的容量的。
- 為了減少 TCAM 的占用,交換機在延時期滿時將會移除沒有被匹配的相應的流表項。
- 控制器根據兩個延時:hard timeout and idle timeout 來管理交換機添加或者刪除流表項,這代表需要在流表的利用率和控制器的負擔之中進行權衡。
- 如果設定很小的 timeout,那么會給控制器帶來額外的負擔。因為控制器可能需要重復添加相同的流表項多次。
- 解決方案
- 當探測 FIN 和 RST 包時立即移除對應的流表項。
- 如果沒有探測到流表項則在設定的 idle timeout 超時時也會被移除。
- 簡單來說,原本要在 idle timeout 期滿時且沒有被匹配時才會移除流表項。那么如果一個連接已經發出了結束的包那么就提前移除而不必等待 idle timeout。
- 所提出的架構有哪些實現難點?
- 無
- 貢獻有哪些?
- 達到最佳的流表利用率而不用增加控制器額外的負擔。
三
- 文章名稱:P4DB: On-the-fly Debugging of the Programmable Data Plane
- 發表時間:2017-10
- 來源:ICNP
- 針對什么問題?
- P4 程序運行時的錯誤無法快速定位并解決。出錯后網絡操作員只能輸出 match-action tables 中所有的表項然后逐個排查。
- 解決方案
- 提出一個通用的調試平臺 —— P4DB
- 允許管理員配置一系列原語從而在三個層次(network level、device level、table level)上進行調試 P4 程序。
- 所提出的架構有哪些實現難點?
- 無
- 貢獻有哪些?
- 據作者所知,P4DB 是第一個用于調試運行時錯誤的調試平臺。
- 提出三個全新的設計:一、促進解決不同的運行時的錯誤;二、簡化調試的流程;三、 提供不同級別的可視化;
- 運行了基于 P4-specific PDP 和 hypervisorspecific PDP 的 P4DB 原型。相應的執行了全面的測試,結果顯示只需要增加很小的性能負擔。
轉載于:https://www.cnblogs.com/multhree/p/9710688.html
總結
- 上一篇: JSON在PHP中的基本应用
- 下一篇: Swift5.1 语言指南(一) 关于S