More on ath10k_flush.

[Michal Kazior]

On 1 April 2014 15:12, Ben Greear <greearb at candelatech.com> wrote:
> On 03/31/2014 10:44 PM, Michal Kazior wrote:
>> On 1 April 2014 02:24, Ben Greear <greearb at candelatech.com> wrote:

[...]

>>> Do we need to somehow shut down all tx logic during the ath10k_flush
>>> so that (other?) stations cannot transmit?
>>
>>
>> This seems strange. drv_flush() is called with all tx queues being
>> stopped in mac80211 with IEEE80211_QUEUE_STOP_REASON_FLUSH. I guess
>> you can still receive a few frames (due to SMP with many interfaces),
>> but that's it (at most num_cpus-1 I guess). You shouldn't be seeing
>> 4000 frames being queued while you flush.
>
>
> Subsequent debugging makes me think the extra packets are not coming
> from the upper stack.  Possibly there are ath10k<->firmware management
> messages
> being queued or something like that?

ath10k_flush() waits only for HTT Tx. It doesn't even wait for
management Tx (it probably should..).

There's a limit to the number of outstanding HTT Tx requests - it is
1424 (+n_cpus - 1). So it is possible to see at most this much frames
being completed while waiting for a flush.


Michał