[Make-wifi-fast] [PATCH v7] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue.

[Toke Høiland-Jørgensen]

Toke Høiland-Jørgensen <toke at toke.dk> writes:

> Dave Taht <dave.taht at gmail.com> writes:
>
>>> Ah, no, those are not panics, those are warnings being triggered by the
>>> fast_tx pointer going while the packet was queued. Now, the
>>> xmit_fast_finish() function doesn't actually use that for anything other
>>> than crypto key configuration, so it would probably be feasible to get
>>> rid of that check in the dequeue path.
>>>
>>> How many of those warnings do you see?
>>
>> I'm not crazy, I run the rrul test at the conclusion of the run. Which this was.
>>
>> I'll go run it on a fresh boot but...
>>
>> dmesg | grep 'cut here'
>>
>> [  707.011531] ------------[ cut here ]------------
>> [  707.343296] ------------[ cut here ]------------
>> [  707.676275] ------------[ cut here ]------------
>> [  708.009204] ------------[ cut here ]------------
>> [  708.342138] ------------[ cut here ]------------
>> [  709.247082] ------------[ cut here ]------------
>> [  709.580053] ------------[ cut here ]------------
>> [  709.913023] ------------[ cut here ]------------
>> [  710.245975] ------------[ cut here ]------------
>>
>> Also attached.
>>
>>> And what do you have to do to get
>>> traffic to flow again?
>>
>> Seems to come back after a while.
>
> Right. Put up a bunch of new images (the ones with version +3).
> Completely untested, but should get rid of the need for the fast_tx
> pointer. See if you can blow those up? :)

BTW, if you do test these, please test them with crypto on (as well).
That's where the largest potential for things blowing up is. :)

-Toke