接下来我们就一起去研究一下吧!
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
port 0（或1,2,3,4） -> switch -> port 6 -> GMAC1 -> PPE; 到此packet被送到PPE模块；
PPE模块根据packet的，SRC IP:Port 和DST IP:Port，算得一个HASH ID，并把该HASH ID存到RX BD里面并由后续的驱动存到skb->cb里面，这个HASH ID是后面驱动处理的关键信息；
PPE模块里面有4K条FOE entry用来记录每条NAT session；上面算出来的HASH ID就是用来索引这里的FOE entry的；同时FOE entry也会记录数据包的SRC IP:Port 和DST IP:Port；
由于这是第一个packet，因此此条flow的状态是未命中，未命中的情况是要送到CPU由软件去处理的；
至此，送至PDMA并产生中断，让CPU来处理这个包；
CPU正常处理该报文，上送协议栈，并做正常的software的NAT，这些没什么不同；
CPU软件的NAT做完之后，要通过以太网再发出去，在以太网驱动的xmit函数里面有个hook_tx, 这就是关键所在，重要的工作都是在hook_tx完成的；
在TX hook里面，分析skb的数据，因为此时的skb已经是经过NAT之后的IP和Port了;同时，由于skb是转发的情况，skb的data和header都是zero copy的，也就意味着可以从skb的cb里面取出在上面存入的HASH ID；
根据取出的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了；
PPE也就知道该如何做NAT了，接下来在收到同样的packet，PPE就照葫芦画瓢的做NAT就是了；同时该条FOE entry的状态也会被设置为bind；
[187768.931427] ==========<Flow Table Entry=2146 (af1a9ea0)>===============
bind完成之后的package flow：
port 0（或1,2,3,4） -> switch -> port 6 -> GMAC1 -> PPE
PPE check the status为hit bind，则PPE按照FOE entry里面的描述做对应的NAT，并发送到对应的port（这里是GMAC1）；就不必打扰CPU了；
