一块儿来Fit TDMA over WiFi(2)

3 收发流程分析与改进

　　收发流程分析涉及到具体代码，属于SDK驱动内容，不能彻底公开，仅供参考，本系列文档中涉及到具体功能或代码时，请在本身的驱动代码中查找。

　　QCA驱动从9.5开始，将原来的htc的功能重构了一下，分红Direct Attach（DA）和Offload（OL）两大部分，前者支持Mips架构的全部SOC，以及非11AC 网卡；后者支持ARM体系的SOC，以及11AC网卡。

　　本内容主要以DA架构为主，OL架构只说起，OL架构的收发流程在MAC层上与DA架构相似。

3.1 流程简述

　　本小节仅涉及数据报文收发流程中与Fit-TDMA相关的关键部分，不重复QCA PDF中tx和rx flow。　　

• TX流程简述

　　TX起始于dev_xmit_queue，而后会走到ath_tx_send_normal或ath_tx_send_ampdu，在ath_tx_send_XXX（normal或ampdu）中，直接调用ath_tx_txqaddbuf直接提交到HAL的硬件队列，由硬件发送；或者有ath_tx_queue_tid临时缓存到tid队列中，经过ath_txq_schedule，将报文提交的HAL的硬件队列发送。所述tid队列为软队列，一共有17个，其中0~15与DSCP域值对应，而16为管理与控制帧队列（不包含信标帧）。所述硬件队列，一共有10，其中0-3号与17个tid队列映射，也就是0-3号队列为数据队列，它们的优先级与WMM的4个AC的优先等级一一对应；9号队列为信标帧队列；队号越高，在硬件中的发送优先级越高。

　　TX发送完毕后，由ath_tx_complete_buf负责完成收尾工做，如更新统计、回收资源等。

• RX流程简述

　　RX起始于ath_intr，而后走到ath_rx_process，再而后走到Ieee80211_input，最后会osif_receive处理，是提交的网络协议栈仍是直接完成报文接收。在此流程中，数据报文会被ath_net80211_rx处理。

3.2 流程修改

　　基于TX流程，直接发送函数是ath_tx_send_normal和ath_tx_send_ampdu，直接调度函数是ath_txq_schedule（内部直接调用ath_tx_sched_aggr或ath_tx_sched_normal）。为了实现Fit-TDMA调度，须要将这3个发现相关的核心功能函数。此外，驱动还有个APONLY的宏，启用了该宏后，报文会从UMA直接跳转到HAL，绕过了这3个核心函数，所以，在启用Fit-TDMA功能时，须要关闭此宏。

　　在ath_tx_send_XXX中，现有逻辑是：若是可直接发送，则当即调用ath_tx_txqaddbuf，将报文直接提交到HAL层发送。而Fit-TDMA是发送报文统一调度，所以，咱们须要将这个功能关闭，强制报文先进入tid队列，而后经过ath_txq_schedule来调度。而在ath_txq_schedule中，现有逻辑是：若是待调度的tid未阻塞，则将该tid的报文，经过ath_tx_sched_aggr 或ath_tx_sched_normal提交的HAL发送之。显然，在tid粒度级上的调度，是不符合Fit-TDMA调度预期的。Fit-TDMA调度是目标终端级粒度的调度。所以，在ath_txq_schedule中，在验证当前tid为非阻塞后，还须要测试tid->an->an_node所指向的目标终端，是否能够发送（便是否为Fit-TDMA Active态），若是不能发送，则一样要将此tid插入paused_tid_q，等待下次调度。

　　进一步地，在实际测试中发现，管理类帧最好不要延时发送，故在具体实施时，仅当tidno小于16，且ac的qnum小于4时，才测试报文目标终端的状态；此外，有部分报文的目标终端是VAP本身、或一个广播地址，这类报文最好也直接放行。另外，若是一个终端已经下线了，但缓存的报文还未发送时，须要直接将该tid所包含的报文空间释放，并将tid资源回收。

　　此外，还须要注意此情况：触发ath_txq_schedule的txq的tid是一个数据包，但由于其目标终端的Fit-TDMA状态为“等待”，故该报文不能被当即调度到HAL层。此时，若是AP处于低流量工做状态，例如管理的终端数小于5个，且只是简单Ping终端。则下一个同tid调度ath_txq_schedule会来的比较慢，致使回包不及时。这样就会看到ping包时断时续。简单的对策是：若是触发调度的tid是个数据包，但本次调度，未能成功下发一个数据报文时，则当即调度该sc的中sc_txq{0,1,2,3}队列中其它队列。这样，可能会出现：要么外发一个数据报文，要么就不能外发数据报文。当不能外发数据报文，则代表当前Fit-TDMA Active态的终端没有待下发数据报文，应当即通知Fit-TDMA 调度者，请求它将活动令牌传递给下一个轮询终端。

　　最后，为了通知终端可发送报文，Fit-TDMA 调度者在完成本地活动令牌轮转后，当即经过管理帧通知目标终端可发送报文到AP。

　　基于RX流程，直接在ath_net80211_rx函数中处理Fit-TDMA接收逻辑，若是启用“严格TDMA策略“，则针对数据报文，首先验证发端是否为Fit-TDMA Active态，若是验证为否，则直接释放接收到的wbuf。若是启用“兼容TDMA策略“，则继续启用现有逻辑。

　　在实际测试中，若是直接丢弃wbuf，则针对无重发保证的网络应用，会形成大量通讯中断。如ping包会丢得一沓糊涂。

　　OL架构中，发送修改点在ol_tx_send函数中，接收修改点在ol_rx_indication_handler，由于网卡级的收发均在黑盒子的FW中，因此目前在offload目录下的驱动修改效果均很差，留待继续改进或换方案。

4 TDMA 调度者

　　TDMA调度者为Fit-TDMA的决策功能体，属于新开发功能模块。具体留待下篇文档说明。