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

但凡牽涉到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)。之所以不能數據回退，其原因在于沒有維護之前狀態的寫指針所導致。

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