>> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
