報文解析規(guī)則定義 流水線劃分提取方案

編 者 按

之前看一篇論文《A Fast Approach for Generating Efficient Parsers on FPGAs》，里面主要講的是如何將P4的報文解析通過流水線技術(shù)映射到FPGA上實現(xiàn)。我本身不研究P4，但這篇文章里面所提到的在構(gòu)造報文解析流水線部分倒頗有意思，故作總結(jié)，感興趣的小伙伴可以去翻看原文。

報文解析規(guī)則定義

這里采用原文中定義的報文頭規(guī)則定義：

這里面定義了七種報文頭規(guī)則(編號為A～G)：

A:Ethernet—>MPLS—>MPLS—>EoMPLS—>Ethernet

B:Ethernet—>IPV4

C:Ethernet—>IPV6

D:Ethernet—>MPLS—>IPV4

E:Ethernet—>MPLS—>MPLS—>IPV4

F:Ethernet—>MPLS—>IPV6

G:Ethernet—>MPLS—>MPLS—>IPV6

流水線設(shè)計所需要盡可能的避免Stall，在真實的業(yè)務(wù)里，可能面臨的是遠比這些更復(fù)雜的協(xié)議。這里我們可以定義。

流水線劃分提取

在網(wǎng)絡(luò)報文解析里，只有當(dāng)前一層報文頭解析完后才能解析下一層報文規(guī)則，故而在流水線設(shè)計里，每一級流水線一般只解析一層報文頭。以上面的流水線為例，首先找出最長路徑:

這里同時為各個報文頭子規(guī)則進行編號?？梢钥吹剑铋L規(guī)則包含了五個報文頭規(guī)則，也就意味著流水線最長級數(shù)為5級。

接下來就是處理沒有在最長路徑上的節(jié)點。以IPV6為例。這里從(1)、(2)、(3)均有可能跳轉(zhuǎn)至IPV6(7)。取其離根節(jié)(1)點最遠的父節(jié)點并掛載在其下面，刪除其他對應(yīng)的跳轉(zhuǎn)關(guān)系：

最終IPV6節(jié)點被放置在EoMPLS同一級節(jié)點處。處于流水線的第四級。這時針對IPV6報文頭的解析，將被放置在流水線第四級進行處理：

Ethernet—>IPV6：第一級流水解析Ethernet，第二三級不做處理，第四級解析IPV6。

Ethernet—>MPLS—>IPV6：第一級解析Ethernet，第二級解析MPLS，第三級不做處理，第四級解析IPV6。

Ethernet—>MPLS—>MPLS—>IPV6：第一級解析Ethernet，第二級解析MPLS，第三級解析MPLS，第四級解析IPV6。 同樣，按照相同的規(guī)則，我們可以來處理IPV4報文頭：

至此，整個流水線設(shè)計調(diào)度完成。流水線共分為五級。

針對上面的七種報文規(guī)則，我們可以一次編號為

在流水線設(shè)計中，每一級報文解析完成后攜帶當(dāng)前已成功解析的標(biāo)志頭headerType以及EthType。這里的流水線主要在于第四級的設(shè)計，其他級都較為簡單，為單一的匹配。在第四級里，定義了7種可能的組合：

headerType=1，流水匹配中IPV4(6)，則headerType=6，報文命中規(guī)則B

headerType=2，流水匹配中IPV4(6)，則headerType=6，報文命中規(guī)則D

headerType=3，流水匹配中IPV4(6)，則headerType=6，報文命中規(guī)則E

headerType=1，流水匹配中IPV6(7)，則headerType=7，報文命中規(guī)則C

headerType=2，流水匹配中IPV6(7)，則headerType=7，報文命中規(guī)則F

headerType=3，流水匹配中IPV6(7)，則headerType=7，報文命中規(guī)則G

headerType=3，流水匹配中EoMPLS(4)，則headerType=4，可能命中報文命中規(guī)則A(到第五級進一步判斷)。

如此，經(jīng)過五級流水線處理，我們可以判斷出在報文是否命中定義的規(guī)則。

個人思考

論文中這種流水線的設(shè)計思想確實值得借鑒。然而真實的業(yè)務(wù)模型里面的報文規(guī)則遠遠比上面的復(fù)雜許多，所造成的流水線級數(shù)勢必會更深更長。且考慮到報文頭不定長度的存在，在每一級流水里都不可避免的出現(xiàn)數(shù)據(jù)位移。這種不定長度的數(shù)據(jù)位移在FPGA里面像現(xiàn)在普遍的512比特位寬情況下還是很消耗資源的(部分級流水可能只需要常數(shù)移位)。

作者的初衷在于建立P4到FPGA的通用映射，然而這里面所設(shè)計的帶寬可能是遠大于真實業(yè)務(wù)設(shè)計所需求的帶寬的。如果想精簡資源個人倒覺得可以借鑒這種報文解析調(diào)度方式采用狀態(tài)機的形式來進行處理，畢竟在真實的業(yè)務(wù)場景里還是很少出現(xiàn)每拍處理一個報文頭的場景?？梢愿鶕?jù)不同報文規(guī)則的長度，需要的帶寬以及狀態(tài)機的最大跳轉(zhuǎn)次數(shù)(對應(yīng)這里的流水線級數(shù))放置相應(yīng)數(shù)量的狀態(tài)機個數(shù)，并通過RR調(diào)度保序輸出來確保真實需要帶寬。

審核編輯：湯梓紅