（9）高通AP10.4开发者指南——WLAN（2.3 Buffer管理）

2.3 Buffer管理（Buffer Management）

这部分主要对驱动内部的buffer进行一个抽象的描述，之所以抽象出来，是因为“frame”可以作为一个通用的概念，其与网络协议栈buffer的匹配原理，可以独立于不同的OS环境以方便描述。本部分还对TX/RX frame buffer在驱动内部是如何管理的，进行了描述。

2.3.1 WBUF抽象（WBUF abstraction）

2.3.1.1 Wbuf

每个wbuf（wireless buffer）对象都代表一个独立的network buffer。在WLAN中，它还可以代表一个从协议栈传递下来的MSDU。底层的驱动模块，会将wbuf作为一个wbuf_t类型的对象来处理，并通过定义好的API来对其进行访问。wbuf相关的API定义在include/wbuf.h文件中。每个平台都应该在其OS抽象层（OS abstraction layer）提供这类API。通常wbuf会跟native network buffer结构体匹配。在Linux平台中，wbuf跟skb结构体匹配。

2.3.1.2 WBUF的类型（WBUF Type）

每个WBUF对象都有其对应的类型。如表2-2所示：
表 2-2 WBUF类型

类型 释义 WBUF_TX_DATA 由网络协议栈下发的normal Tx data frame WBUF_TX_MGMT 内部生成的management frame WBUF_TX_BEACON 内部生成的beacon frame WBUF_RX Rx DMA中用到的Rx buffer WBUF_TX_CTL 内部生成的control frame

2.3.1.3 一些开发规则（Limitations）

理论上讲，抽象化的wbuf应该有等同于native network buffer一样的功能。即wbuf抽象化后，其目的是想支持不同的平台，不过目前，只能支持一些具有相同子集的API的操作系统，比如Linux、NetBSD、Windows Vista。需要注意的是：

• 开发人员不应该认为wbuf在物理上是连续的。一个wbuf由多个物理内存碎片组成。
• 开发人员不应该将一个packet等同于一个Ethernet frame或者IEEE 802.11 frame。只有经ieee80211_encap()函数调用后，才能得到一个视为IEEE 802.11 MPDU的wbuf。
• 开发人员不应该将LLC/SNAP header所占用的物理内存碎片，视为与WLAN header一样。同理，TCP/IP header也不能视之一样。
• 开发人员不应认为wbuf与一块足够大的context区域相匹配。
• wbuf可以通过一些公共的API来访问（函数定义在include/wbuf.h文件中），但是并不是所有的API都可以应用到每一个wbuf型。

2.3.2 描述符抽象化（Descriptors Abstractions）

WLAN硬件使用descriptor作为载体，在driver和MAC hardware之间来传输frame（抽象为wbuf）。low-level 的driver主要负责为MAC hardware提供一系列的descriptor。然后MAC会解析descriptor，并完成成一系列data的传输。对于MAC处理descriptor的一些细节，请参考WLAN hardware芯片的data sheet文档。
在WLAN driver中， descriptor被组织成许多对physical和virtual的descriptor。driver使用physical descriptor与MAC进行交互。他们通常在整个driver的生命周期中，有固定的DMA区域，他们不能缓存一些能够阻止CPU检测MAC hardware或vice versa产生的更新的数据。一个physical descriptor由ath_desc结构体表示，定义在hal/ah_desc.h文件里。
physical descriptor不应该作为一个罕见的资源来看待。任何仅由driver访问的control和status信息，都应该放到virtual descriptor中，virtual descriptor会从normal memory pool中分配。virtual descriptor和physical descriptor是一对一的关系。ath_buf结构体代表了一个virtual descriptor实例，定义在ath_dev/ath_desc.h文件中。ath_buf结构体的指针bf_desc，会指向其对应的physical descriptor。
virtual descriptor由一个BSD类型的尾队列（TAILQ）——ath_dev实例来管理。physical descriptor只能由其对应的virtual descriptor来访问。descriptor list如表2-2所示：

表 2-2 Descriptor List

保存在ath_buf结构体中的信息，有以下内容：

• 对driver和hardware（bf_mpdu）之间，传递数据的载体——wbuf的引用。
• data所处的Physical和Virtual地址之间的转换。
• LMAC TX/RX处理所需的TX descriptor flags和RX status flags。

2.3.3 接收buffer的管理（Receive Buffer Management）

作为RX初始化流沉的一部分，ATH_RXBUF宏，定义了RX descriptor的数目，根据这个数目，ath_buf会被分配出来。对于每一个ath_buf，能够预先分配一些WBUF_RX类型的wbuf。所有这些ath_buf都会link成TAILQ，TAILQ_HEAD在sc_rxbuf存储。
从硬件收到frame，LMAC就会从sc_rxbuf TAILQ中移除对应的ath_buf，并完成frame Rx处理。然后从ath_buf中移除WBUF的索引，并将这个索引传递到UMAC和网络协议栈继续处理。然后，一个新的WBUF会被分配出来，ath_buf会link到这个新的wbuf，然后被追加到sc_rxbuf TAILQ的尾部。

2.3.4 发送buffer的管理（Transmit Buffer Management）

作为TX初始化流程的一部分，ATH_TXBUF宏，定义了TX descriptor的数目，根据这个数目，ath_buf会被分配出来。这些ath_buf会link成TAILQ ，TAILQ_HEAD在sc_txbuf存储。对于任何从UMAC传递到LMAC的frame（已经放在wbuf中），LMAC层都会从sc_txbuf list中将其对应的ath_buf移除。一旦这一Tx frame处理结束，LMAC会释放其对应的wbuf，并将ath_buf重新排列到sc_txbuf list中。