[Make-wifi-fast] [ath9k-devel] [PATCH 1/2] ath9k: use mac80211 intermediate software queues

[Dave Taht]

>>  struct ath_atx_tid {
>>       struct list_head list;
>> +     struct sk_buff_head i_q;
> Do we really need a third queue here? Instead of adding yet another
> layer of queueing here, I think we should even get rid of buf_q.

Less queues, more filling!

>
> Channel context based queue handling can be dealt with by
> stopping/starting relevant queues on channel context changes.

what can be done to reduce the impact of channel scans?

http://blog.cerowrt.org/post/disabling_channel_scans/

> buf_q becomes unnecessary when you remove all code in the drv_tx
> codepath that moves frames to the intermediate queue.
>
> Any frame that was pulled from the intermediate queue and prepared for
> tx, but which can't be sent right now can simply be queued to retry_q.
>
> This will also help with getting the diffstat insertion/deletion ratio
> under control ;)

The ideas here can apply elsewhere, also. Are you still actively
working with the mt76?

Anything else "out there" besides that and the ath5k worth looking at?

Am I seeing patches and firmware changes for better statistic keeping
on the ath10k that look promising for airtime fairness... or am I
delusional?

> elsewhere powersave was mentioned

How big can a powersave queue get?