一起来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的决策功能体,属于新开发功能模块。具体留待下篇文档说明。


本文章由作者:佐须之男 整理编辑,原文地址: 一起来Fit TDMA over WiFi(2)
本站的文章和资源来自互联网或者站长的原创,按照 CC BY -NC -SA 3.0 CN协议发布和共享,转载或引用本站文章应遵循相同协议。如果有侵犯版权的资 源请尽快联系站长,我们会在24h内删除有争议的资源。欢迎大家多多交流,期待共同学习进步。

相关推荐