mtk平台的暗碼?PPE - Packet Processing EngineFOE - Frame Offload Engine，今天小編就來聊一聊關于mtk平台的暗碼?接下來我們就一起去研究一下吧!

mtk平台的暗碼

PPE - Packet Processing Engine

FOE - Frame Offload Engine

PDMA - Packet DMA

現在LEDE上已經對UBNT ERX支持了，但是其中對性能有很大提高的HNAT（Hardware NAT）功能還沒有實現；這裡就嘗試把HNAT的支持移植到ERX上，以此來了解MT7621的 HW NAT功能。

______________________

CPU

______________________

PDMA

______________________

PPE

______________________

GMAC1 | GMAC2

______________________

port 6 | port 5

---------------------------------

port 0,1,2,3, 4

______________________

在目前的LEDE代碼裡面隻用了GMAC1，也就是port 5與GMAC2之間的link是force down的

PPE Enabled: GMAC<->PPE<->CPU

PPE Disabled: GMAC<->CPU

• 第一個包packet flow：

1. port 0（或1,2,3,4） -> switch -> port 6 -> GMAC1 -> PPE; 到此packet被送到PPE模塊；

2. PPE模塊根據packet的，SRC IP:Port 和DST IP:Port，算得一個HASH ID，并把該HASH ID存到RX BD裡面并由後續的驅動存到skb->cb裡面，這個HASH ID是後面驅動處理的關鍵信息；

3. PPE模塊裡面有4K條FOE entry用來記錄每條NAT session；上面算出來的HASH ID就是用來索引這裡的FOE entry的；同時FOE entry也會記錄數據包的SRC IP:Port 和DST IP:Port；

4. 由于這是第一個packet，因此此條flow的狀态是未命中，未命中的情況是要送到CPU由軟件去處理的；

5. 至此，送至PDMA并産生中斷，讓CPU來處理這個包；

6. CPU正常處理該報文，上送協議棧，并做正常的software的NAT，這些沒什麼不同；

7. CPU軟件的NAT做完之後，要通過以太網再發出去，在以太網驅動的xmit函數裡面有個hook_tx, 這就是關鍵所在，重要的工作都是在hook_tx完成的；

8. 在TX hook裡面，分析skb的數據，因為此時的skb已經是經過NAT之後的IP和Port了;同時，由于skb是轉發的情況，skb的data和header都是zero copy的，也就意味着可以從skb的cb裡面取出在上面存入的HASH ID；

9. 根據取出的HASH ID通過查找foe entry可以找到該數據包NAT之前的SRC IP:Port 和DST IP:Port，然後根據現在的數據包内的數據可以找出NAT之後的SRC IP:Port 和DST IP:Port；這樣NAT之前和之後的SRC IP:Port 和DST IP:Port都有了，這就是一條完整的NAT session了；

10. PPE也就知道該如何做NAT了，接下來在收到同樣的packet，PPE就照葫蘆畫瓢的做NAT就是了；同時該條FOE entry的狀态也會被設置為bind；

• FOE entry 的一個例子：

[187768.931427] ==========<Flow Table Entry=2146 (af1a9ea0)>===============

1. port 0（或1,2,3,4） -> switch -> port 6 -> GMAC1 -> PPE

2. PPE check the status為hit bind，則PPE按照FOE entry裡面的描述做對應的NAT，并發送到對應的port（這裡是GMAC1）；就不必打擾CPU了；

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!