PPE - Packet Processing EngineFOE - Frame Offload Engine,今天小编就来聊一聊关于mtk平台的暗码?接下来我们就一起去研究一下吧!

mtk平台的暗码(应用篇MTK7621HWNAT)

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


  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;


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

  • bind完成之后的package flow:

    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了;

    ,