Re: [Make-wifi-fast] [RFC] ath10k: implement dql for htt tx

[Michal Kazior <michal.kazior@tieto.com>]

On 30 March 2016 at 02:57, Dave Taht <dave.taht@gmail.com> wrote:
> As a side note of wifi ideas complementary to codel, please see:
>
> http://blog.cerowrt.org/post/selective_unprotect/
>
> On Tue, Mar 29, 2016 at 12:49 AM, Michal Kazior <michal.kazior@tieto.com> wrote:
[...]
>> On the other hand DQL will react also to host system interrupt service
>> time. On slow CPUs (typically found on routers and such) you might end
>> up grinding the CPU so much you need deeper tx queues to keep the hw
>> busy (and therefore keep performance maxed). DQL should automatically
>> adjust to that while "txop limit" might not.
>
> Mmmm.... current multi-core generation arm routers should be fast enough.

While this helps it doesn't mean you can magically un-serialize
interrupt/txrx completion work.


[...]
>>>> To sum things up:
>>>>  - DQL might be able to replace the explicit txop queue limiting
>>>> (which requires rate control info)
>>>
>>> I am pessimistic. Perhaps as a fallback?
>>
>> At first I was (too) considering DQL as a nice fallback but the more I
>> think about the more it makes sense to use it as the main source of
>> deriving time slices for tx scheduling.
>
> I don't really get how dql can be applied per station in it's current forrm.

I was thinking of the following scheme:
 - disable excessive retries in fw (apparently doable via WMI pdev parameter)
 - deficit-based round-robin over stations
 - maintain DQL structure per station
 - when station gets its turn to xmit push frames to fw
 - keep doing that (with regard to per station DQL limits) until either:
   - associated software queue becomes empty
   - 1 timeslice for given station has elapsed
     - i was thinking of extracting timeslices from DQL or maintaining
it separately
 - try next station
 - do not submit packets to multiple stations at once (MU will need
more work..), i.e. always drain tx completely before switching to next
station
 - each station may need a different timeslice (to squeeze out max
burst performance)


[...]
>>>> PS. I'm not feeling comfortable attaching 1MB attachment to a mailing
>>>> list. Is this okay or should I use something else next time?
>>>
>>> I/you can slam results into the github blogcerowrt repo and then pull
>>> out stuff selectively....
>>
>> Good idea, thanks!
>
> You got commit privs.

Yep, thanks!


Michał