本週的第二節課延續上一節課關於晶片設計的討論，講完報文處理流水線的設計以後，開始講可程式設計流量管理的設計。

排程器和報文處理在分組網路裡面就是通常說的Packet Processor和Traffic Manager晶片，通常用PP和TM指代。

PP的設計有多種流派，主要針對二層報文處理和三層報文的處理可以有不同的優化。Silicon ONE採取的是RTC結構，可以用許多個微核做出眾核結構，配合內部的資源排程器將報文排程到不同的微核上進行處理，每個微核完成針對報文的全部處理任務，也就是Run to Complete的RTC。這種結構有它的優勢，可以利用多核處理器的設計方法、容量可以通過增加微核的數量來擴充套件，但是問題是如何實現高效的排程、如何針對大象流也能做到線速。PP也可以是Pipeline結構，比較適合於報文處理規則相對簡單的二層交換應用。

本節課是講可程式設計的流量管理晶片的設計，文章介紹說TM通常採用固定的設計，支援哪些排程演算法通常是固化在晶片裡面的，可程式設計能力非常有限。

文章提出了一種可程式設計TM設計，它基於報文的排程本質上是安排每個報文的發生順序和傳送時間的問題，而傳送順序和時間在報文進入佇列之前就可以確定下來。

文章以此為基礎，提出了通過在報文進入佇列前計算報文傳送順序和傳送時間，進而基於計算結果講報文插入到一個PIFO優先順序佇列，傳送端固定從佇列頭取報文傳送的可程式設計TM結構。

PIFO結構是一種Push in, First out結構，不同的佇列排程演算法決定了Push in的不同位置。

這種結構不需要為每個流保留一個佇列，僅僅需要為每個Egress埠保留一個佇列就可以了。

文章確認了PIFO結構可以實現的排程演算法，也指出了其不能支援的排程演算法。

文章開源了C++演算法和Verilog實現，通過模擬綜合比較了可程式設計TM結構需要的資源情況。

文章的結論部分機器翻譯+手工校對：

直到最近，人們還普遍認為最快的交換晶片應該是固定功能的;可程式設計裝置不可能有同樣的效能。最近對可程式設計解析器、快速可程式設計交換流水線和程式語言的研究，以及最近的Tbit /s可程式設計商業晶片的研究表明，情況可能正在變化中。

但到目前為止，人們一直認為對包排程程式進行程式設計是不可能的——部分原因是所需的演算法是如此多樣，而且因為排程程式位於共享包緩衝區的核心，在這裡，計時需求是最緊迫的。

人們普遍認為，很難找到一個有用的抽象，同時也能在快速硬體中實現。

pifo似乎是一個非常有前途的抽象:它們包括各種現有演算法，並允許我們表達新的演算法。此外，它們可以在適度的芯片面積開銷下以線路速率實現。

我們相信，最令人興奮的結果將是產生許多新的排程程式，由網路運營商發明、迭代和改進，然後根據自己的需要部署。

研究實驗將不再侷限於模擬和進度的限制，由供應商的選擇排程演算法。那些需要新的演算法的人可以建立他們自己的演算法，甚至可以從開源儲存庫或可複製的SIGCOMM論文中下載一個。

為了實現這一目標，我們將需要真正的具有可程式設計PIFO排程器的交換晶片。好訊息是，我們沒有理由認為未來的交換晶片不能包含可程式設計PIFO排程器。

名校就是名校，這課程設定和進度，緊貼業界最前沿。