[rt2x00-users] [PATCH 2/3] rt2x00: move rt2800_txdone() to rt2800usb.c

[Helmut Schaa]

Hi Ivo,

Am Mittwoch, 22. Dezember 2010 schrieb Ivo Van Doorn:
> > Hence, I don't see a possibilty to integrate the rt2800usb_txdone_entry_check
> > into rt2800pci again without removing the whole (pid != pid_tx) check.
> >
> > But as far as I understood this helps quite well on rt2800usb?
> 
> Yes, but it hasn't been intensively tested with aggregation yet.
> so the problem might exist on there as well.

Could be, yes.

> But it does mean however that in rt2800pci we have less
> accuracy on the TX status reporting.

Unfortunately, yes.

> If we haven't received the
> TX status for a frame. Instead of detecting that, and fixing it,
> it will simply start reporting the incorrect TX status for _every_
> subsequent TX frame which is being send.

Yep, that's not a satisfactory situation either. The question is,
which way is the better one. And for rt2800pci it is (at least at the
moment from my point of view) to not check the tx status reports.
However, the wcid check seems to be the only one that doesn't ever
fail :P (but that will only help in AP mode).

Ivo, if you agree I'll do the following:

Change rt2800_txdone_entry_check to _only_ check if the txwi params
match the tx status details and return true or false. And move the
rt2x00lib_txdone_noinfo out into the caller function (we've already got
rt2800_txdone which is used by rt2800usb and rt2800pci_txdone for PCI).

In rt2800pci we just print a warning for each mismatch and for rt2800usb
we do the rt2x00lib_txdone_noinfo magic. That way we get at least a warning
on rt2800pci and keep the apparently "good" behavior of rt2800usb. If there
are still lost tx status reports on PCI we will at least get a report based
on the warnings in the kernel log.

Does that shound ok for you (as long as we don't know if rt2800usb suffers
from the same problem and don't know a better way to improve the check)?

Merry Christmas,
Helmut

PS: For aggregated frames we could also do the following (but that will take
quite some time): AMPDUs are BlockAcked, so we could simply parse all
BlockAcks in software to check each frames (based on the seqno) tx status.
That would also allow us to know which frames were put into the same AMPDU and
improve the interaction with minstrel_ht. But I guess it's quite some code :(
that needs to be written as we have to take retries into acount and single
failed frames were successive frames succeeded and ...