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

》關(guān)于緩存與丟包，如何控制 ? ?

先來談?wù)勔话阆?00G Mac 這種類似的IP的Rx的特點:

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

一般帶有sop、eop

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

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

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

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

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

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

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

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

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

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

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

如果從設(shè)計“精益求精”的角度，這里的設(shè)計能否“優(yōu)化下呢？”

》異形FIFO

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

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

????關(guān)于FIFO的原理，估計大多數(shù)面試官都可能會問到過，F(xiàn)IFO狀態(tài)的維護說白了就是一個讀指針(read_ptr)和一個寫指針(write_ptr)。之所以不能數(shù)據(jù)回退，其原因在于沒有維護之前狀態(tài)的寫指針所導(dǎo)致。

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

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

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

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

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

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

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

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

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

????至于讀側(cè)，則可以正常根據(jù)read_ptr,write_ptr來進行處理，天然的實現(xiàn)了整包輸出的特性。

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

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

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

》代碼附錄 ????

最后，貼上完整的代碼：

審核編輯：劉清