Re: [PATCH v2] ath10k: parse Rx MAC timestamp in mgmt frame for FW 10.4

2016-03-22 Thread Peter Oh
On 03/22/2016 04:14 PM, kbuild test robot wrote: Hi Peter, [auto build test WARNING on wireless-drivers-next/master] [also build test WARNING on v4.5 next-20160322] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https

[PATCH 9/9] ath10k: combine txrx and replenish task

2016-03-22 Thread Rajkumar Manoharan
Since tx completion and rx indication processing are moved out of txrx tasklet and rx ring lock contention also removed from txrx for rx_ind messages, it would be efficient to combine both replenish and txrx tasks. Refill threshold is adjusted for both AP135 and AP148 (low and high end systems).

[PATCH 5/9] ath10k: speedup htt rx descriptor processing for rx_ind

2016-03-22 Thread Rajkumar Manoharan
In follow up patch, htt rx descriptors will be reused instead of dealloc and refill. To achieve that htt rx indication messages should not be deferred and should be processed in pci tasklet itself. Also from rx indication message, mpdu_count alone is used. So it is maintained as atomic variable

[PATCH 6/9] ath10k: register ath10k_htt_htc_t2h_msg_handler

2016-03-22 Thread Rajkumar Manoharan
Except qca61x4 family chips (qca6164, qca6174), copy engine 5 is used for receiving target to host htt messages. In follow up patch, CE5 descriptors will be reused. In such case, same API can not be used as htc layer callback where the response messages will be freed at the end. Hence register new

[PATCH 7/9] ath10k: cleanup copy engine receive next completion

2016-03-22 Thread Rajkumar Manoharan
The physical address necessary to unmap DMA ('bufferp') is stored in ath10k_skb_cb as 'paddr'. For diag register read and write operations, 'paddr' is stored in transfer context. ath10k doesn't rely on the meta/transfer_id. So the unused output arguments {bufferp, nbytesp and transfer_idp} are

[PATCH 1/9] ath10k: speedup htt rx descriptor processing for tx completion

2016-03-22 Thread Rajkumar Manoharan
To optimize CPU usage htt rx descriptors will be reused instead of refilling it for htt rx copy engine (CE5). To support that all htt rx indications should be processed at same context. FIFO queue is used to maintain tx completion status for each msdu. This helps to retain the order of tx

[PATCH 4/9] ath10k: cleanup amsdu processing for rx indication

2016-03-22 Thread Rajkumar Manoharan
Make amsdu handlers (i.e amsdu_pop and rx_h_handler) common to both rx_ind and frag_ind htt events. It is sufficient to hold rx_ring lock for amsdu_pop alone and no need to hold it until the packets are delivered to mac80211. This helps to reduce rx_lock contention as well. Signed-off-by:

[PATCH 3/9] ath10k: remove unused fw_desc processing

2016-03-22 Thread Rajkumar Manoharan
The fw descriptor was never used and probably never will be. It makes little sense to maintain support for it. Remove it and simplify rx processing. This will make it easier to optimize rx processing later as well. Signed-off-by: Rajkumar Manoharan ---

[PATCH 0/9] ath10k: improve throughput performance

2016-03-22 Thread Rajkumar Manoharan
Hi All, In order to reuse HTT Rx descriptor (copy engine 5), HTT response processing should be decoupled from txrx data processing. This change also helps to reduce rx ring lock contention. As txrx tasklet's work load is reduced, rx replenish task can be combined with txrx_task. Refilling

Re: [RFCv2 0/3] mac80211: implement fq codel

2016-03-22 Thread Toke Høiland-Jørgensen
Michal Kazior writes: > traffic-gen generates only BE traffic. Everything else runs UDP_RR > which doesn't generate a lot of traffic. Good point. Fixed that: the newest git version of traffic-gen supports a -t parameter which will be set as the TOS byte on outgoing

Re: [RFCv2 0/3] mac80211: implement fq codel

2016-03-22 Thread Michal Kazior
On 21 March 2016 at 18:10, Dave Taht wrote: > thx. > > a lot to digest. > > A) quick notes on "flent-gui bursts_11e-2016-03-21T09*.gz" > > 1) the new bursts_11e test *should* have stuck stuff in the VI and VO > queues, and there *should* have been some sort of difference

Re: [Make-wifi-fast] [RFCv2 1/3] mac80211: implement fq_codel for software queuing

2016-03-22 Thread Michal Kazior
On 22 March 2016 at 02:35, David Lang wrote: > On Wed, 16 Mar 2016, Michal Kazior wrote: > >> Since 11n aggregation become important to get the >> best out of txops. However aggregation inherently >> requires buffering and queuing. Once variable >> medium conditions to different