一塊兒來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的決策功能體，屬於新開發功能模塊。具體留待下篇文檔說明。