杂谈：WiFi包和buffer

wifi 分为MAC层和PHY层。

（纯属吓）

frames(MPDU)分为以下几个部分：

{MAC_HDR,  {PHY_HDR, PSDU}}, FCS。{PHY_HDR，MAC_HDR, MSDU，FCS}

MAC_HDR:  RA, TA, VHT/HT/HE, MU/SU GROUP ID，BSSID, LENGTH, AMPDU or MPDU flag, CIPHER_TYPE, defragement or not, duration, MANAGE/CONTROL/DATA timestamp，Frame control, Qos control, HT controlfield等非常重要的一种是mangement frame，它是没有data  field,但是它也有“数据”。

PHY_HDR: VHT/HT/HE/MU/SU有不同的格式，格式不统一， AMSDU or MSDU, PHY_MODE, LENGTH，PHY_RATE等。

MAC相应的sequences: 解析MAC_HDR, check LENGTH,  

对应的caching机制： 使用一个RxPHY_FIFO，用来缓存数据， 256 depthx 64 bits.

再使用一个RxParseFIFO， 64 depth x 64 bits. 这个用来缓存相关的数据，等待被解包。需要缓存一个frame。

然后使用RxCache，这一部分是8196x64 bits。这一部分是因为DMA搬的比较慢，所以需要。

出来的数据有RxCache中的数据，以及RxCmdFIFO，还有Descriptor。

RxCmdFIFO是供MAC自己的DMA（Aribitor内）进行数据的搬移而用的。其包含Descriptor(此Descriptor和下面的Descriptor不是一样的），Buffer，这些buffer存储数据，MSDU，MPDU也可非常多样化的结构存储在buffer中也即包含了当前的buffer list的descriptor以及buffer。由于descriptor随着buffer的不断更新（数据包不断被解析）而同样被更新，因此，descriptor只会在最后整个PSDU被收完之后才是真正确定了的。其具有如下的结构：

MPDU以及MSDU的情况（都没有聚合）：

Buffer HDR       PADDING   MAC HDR    msdu payload          TRAILER         FCS        Descriptor

AMSDU的情况：

Buffer0 HDR  PADDING  MAC HDR  sub-msdu payload   Descriptor

Buffer1 HDR  PADDING  MAC HDR  sub-msdu payload 

Buffer2 HDR  PADDING  MAC HDR sub-msdu payload   TRAILER FCS 

对于AMPDU的情况，由于buffer的排布是一种自链接的形式，那么，没有必要和AMSDU有区别。

相应的,对于MPDU以及MSDU的情况，应该都是可以做成和A系列完全类似的方式。

Descriptor是提供的和软件之间的接口。包含：AMSDU or MSDU, AMPDU or MPDU, BufferAddr。Next Buffer or next Descriptor. Last MSDU or not. 所有的数据存储都是由MAC自己来定义的。这样一种接口的好处是，减少了软件对数据调度的干预，尽可能的提高了效率。