但凡牽涉到SmartNIC，都免不了牽涉到MAC IP。在網絡設計里，MAC IP Rx端一般都是不接受反壓的，隨著報文類型對應的處理能力的不一樣，在MAC收包處不可避免的存在報文緩存和丟包。

》關于緩存與丟包，如何控制 ? ?

先來談談一般像100G Mac 這種類似的IP的Rx的特點:

rx接口均為Flow類型(即只有valid而沒有ready)

一般帶有sop、eop

在eop處會指定報文是否有錯誤

????既然不接受反壓(沒有ready)，那勢必需要在流量入口處設置緩存，并當緩存滿時允許丟包。 ???

?由于在報文eop處可能存在錯誤，對于錯誤的報文，往往不會發往數據鏈路的下游，同時有時候下游會要求報文中間不能存在空拍(即要求整拍輸出)。而一提到報文緩存，大多數人想到的就是FIFO，故在很多開源設計里，往往都用FIFO的形式來進行搭建:

????一般會設計兩路FIFO,一路用來存放數據，另一路用來存放報文的信息。對于兩路FIFO的輸入側，一般大多數的設計思路是:

在報文SOP首拍時判斷Data Fifo是否afull拉起(Msg FIFO一般設計的容量足夠滿足不會afull先于Data FIFO拉起),若拉起，則這一幀報文認為無法進行緩存，需丟棄，否則則這一拍報文在處理時，可以直接寫入Data FIFO,無需再考慮afull信號。

在報文eop尾拍時，若該數據報文能壓入Data FIFO，將報文是否有錯誤及一些其他信息壓入Msg FIFO。

????在兩路FIFO的輸出側，一般的設計流程是： 等待兩路FIFO均不會空 從Msg FIFO中判定要處理的報文是否存在Error，若存在Error，將報文從Data FIFO中取出直接丟掉，否則送往下游。在報文EOP時，從Msg FIFO中讀取出該報文。

????流程沒問題，用起來也沒問題。那么接下來我們來分析下這里的設計是否能優化下。 ????

對于進入的網絡報文，Data FIFO從功能上來講是一個嚴格的Package FIFO，一幀報文在sop時能緩存那么就意味著這一幀報文就一定能緩存，所以在設計afull時就需要考慮最大報文長度。以9600Byte為最大報文長度而言，當總線位寬是512 bits時，其緩存需要150個entry。那么在設計Data FIFO時其至少要在還剩下150個Entry沒有使用時就拉高afull。

FIFO本身的作用是吸收瞬時流量，設置如此大的afull閾值是否也就意味著極大的空間浪費？明顯afull拉高時我們甚至有可能還能多緩存150個數據報文(如果這段時間恰好下游處理能力不足)，而這些報文就這么丟棄掉了(當然你可以說我增大FIFO的深度不就完事兒了么，也沒毛病，但空間浪費的情況始終存在)。 ????

其次，為了避免向下游發送錯誤的報文，我們還需要專門維護一個Msg FIFO(當然也可能存儲一些報文長度等類型報文，這里僅考慮存儲是否報存在報文錯誤)。 ????

如果從設計“精益求精”的角度，這里的設計能否“優化下呢？”

》異形FIFO

????回到上面的問題，之所以設置afull也好還是專門設置一個MsgFifo也好其都是因為寫入FIFO的數據不能回退所導致的。當一幀報文在寫入過程中寫到一半發現FIFO滿了這時候會導致有半包數據。當寫到最后一拍數據發現有error標志又無法把這一幀報文給回退掉，故而采取上面的那種設計。

????那么，如果FIFO能回退是否就解決了這個問題？

????關于FIFO的原理，估計大多數面試官都可能會問到過，FIFO狀態的維護說白了就是一個讀指針(read_ptr)和一個寫指針(write_ptr)。之所以不能數據回退，其原因在于沒有維護之前狀態的寫指針所導致。

????那么這里我們不妨維護一個能回退狀態的指針即可：

????這里我們用write_ptr來維護數一幀數據報文成功寫入后的指針，write_ptr_tmp,read_ptr則用于表示正常FIFO的讀寫指針。只不過write_ptr_tmp相較于普通的FIFO有回退的功能。

????對于寫操作，為避免一幀數據報文在寫操作過程中出現中間有一拍出現full而后消失，我們則需要維護一個wen_flag標志寄存器:

????那么對于數據寫使能的處理則可以表示為：

????即當遇到full或者pkg_wen_flag為0或者error時wen均不使能，數據不不再寫入RAM。????

????那么對于write_ptr_tmp，其處理邏輯為：

????在一幀報文進入時，每成功寫入一拍數據，則write_ptr_tmp就會加1，一旦出現數據無法成功寫入，則其立即回退到write_ptr保存值(此時繼以后的報文wen均會拉低)，實現回退功能。

????而對于write_ptr則更為簡單了:

????僅需要在報文的最后一拍判斷是否寫成功，如果寫成功，那么則可以更新write_ptr。

????至于讀側，則可以正常根據read_ptr,write_ptr來進行處理，天然的實現了整包輸出的特性。

????而為方便給用戶提示報文是否寫入成功，我們可以定義如下：

????即判斷最后一拍數據報文能否正常的寫入即可。

????如此，對于FIFO簡單的一點改動，可以使我們充分壓榨RAM的資源，避免因為設計而導致的本不必丟失的報文丟失，何樂而不為呢～

》代碼附錄 ????

最后，貼上完整的代碼：

審核編輯：劉清