[rt2x00-users] rt2x00: status update regarding txdone handling

[Ivo Van Doorn]

On Sun, Aug 8, 2010 at 6:57 PM, Ivo Van Doorn <ivdoorn at gmail.com> wrote:
> On Sun, Aug 8, 2010 at 6:23 PM, Ivo Van Doorn <ivdoorn at gmail.com> wrote:
>> On Fri, Aug 6, 2010 at 2:09 PM, Helmut Schaa
>> <helmut.schaa at googlemail.com> wrote:
>>> Am Mittwoch 04 August 2010 schrieb Helmut Schaa:
>>>> - Does every frame get a tx status? Or in which cases might a tx status get
>>>>   lost and why? Is that easily detectable?
>>>
>>> JFI
>>>
>>> So, I did a few more tests (again) ;)
>>>
>>> In 11g mode I cannot get the the TX_STA_FIFO to lose tx statuses at all
>>> (the CPU utilization is always below 80%).
>>>
>>> In 11n mode (both, with aggregation enabled and disabled) I can get the
>>> TX_STA_FIFO to lose tx statuses (the peak CPU utilization sometimes hits
>>> nearly 100%).
>>>
>>> Next case, also with 11n, I'm not running iperf on the rt3052 but on a second
>>> machine connected to the AP via ethernet:
>>>
>>> STA <-- ethernet --> AP <-- wifi --> STA2
>>>
>>> I can easily get 30Mbps from STA to STA2 and around 20Mbps from STA2 to STA
>>> (I guess that's due to the missing RX aggregation in rt2x00). The CPU
>>> utilization on the AP is below 50%.
>>>
>>> So, it seems to me as if the CPU utilization could be the culprit for the lost
>>> tx statuses (is that the correct plural form of status?). Not sure though ...
>>>
>>> So, what I plan to do soon is to add a watchdog to rt2800pci (similar to Ivo's
>>> USB watchdog) to avoid stuck queues. I've just implemented a prototype that
>>> keeps track of the DMA_DONE interrupts and once a frame is DMADONE'ed but
>>> no TX status was received within a specific time we just report the frame
>>> with an unknown state.That will at least ensure that the AP won't hang and
>>> in the worst case it will deliver frames with less performance then possible
>>> (because of the tx queue resets).
>>>
>>> But for now that approach sounds reasonable to me.
>>
>> I believe this has been suggested by somebody before, but could we extend
>> the usage of the PID field a bit? The field exists of 4 bits, to
>> encode the queue
>> we need only 2 bits (queue 0, 1, 2, 3. We can ignore the beacon queue since
>> there it doesn't matter which PID is used). That means we have 2 bits left
>> to encode a portion of the queue entry index. (We can encode 1, 2 and
>> 3, 0 is not
>> possible since that would generate a PID of 0, and the legacy drivers have taken
>> workarounds to prevent such a value to be written into the TXD, so I assume 0 is
>> invalid as PID).
>>
>> When reading TX status reports, we obtain the queue, and use the queue index
>> to validate if the queue entry index is what we expected. If not, we
>> start reporting
>> frames with UNKNOWN until we reach the entry index which matches the value from
>> the PID.
>>
>> This is not 100% accurate, since it will remain asynchronous when
>> there are more then
>> 3 missing TX status reports, but at least it gives us a chance to move
>> to the correct
>> position in the queue. It would certainly be more accurate then doing
>> this during a
>> watchdog operation where we don't know for sure if the entry we are
>> reporting with
>> UNKNOWN has been reported or not.
>
> See below patch for the general id (compile-test only)
>
> ---
<snip>

Before I forget, this patch would still need something like the watchdog that
you suggested to fix any issues with the TX status loss of 3 or more reports
at once.

Ivo