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

Helmut Schaa helmut.schaa at googlemail.com
Thu Jul 29 23:00:34 AEST 2010


Hi,

Warning: brain dump follows ...

(I don't know if the following also applies to PCI cards as well but it is
easily reproducible on the SoC platform)

I'm still fighting with the txdone handling in rt2800pci. Sometimes the tx
queues get stuck. It took me a few days but it seems as if the TX_STA_FIFO
register limitation to hold max 16 entries is causing this problem.

The more the host CPU is utilized the more often it happens that we read
up to 16 entries from the TX_STA_FIFO which in turn means that a few tx status
entries were already dropped. Hence, some tx ring entries don't get freed as
expected which fills up the queue.

I already tried to read the TX_STA_FIFO contents in hard irq context to get
a higher chance of reading all entries before the hw drops them but even that
didn't work out.

It seems as if either 
1) interrupts are disabled on the host CPU and thus multiple tx status entries
   accumulate before they get processed by the host CPU.
of
2) the wireless chip sometimes issues the tx status interrupt too late and some
   entries from the TX_STA_FIFO are already dropped.

I already tried to split of txdone handling from txstatus handling which works
ok but still once a tx status is lost it is not possible afterwards to match
the status to the right tx'ed frame which means that we get incorrect
statistics which influences the rate control algorithm and thus results in
the selection of a slower tx rate even though a faster one would be good as
well.

Hence, I've come up with the following idea:

Not every tx'ed frame status needs to be reported back to mac80211. There are
a few frames that need a tx status report, but they are marked with 
IEEE80211_TX_CTL_REQ_TX_STATUS by mac80211. All other frames don't require the
tx status. But of course the tx status is also used by the rate control
algorithm.

That's why I though about limiting the number of frames that require a tx
status (including a number of "normal" frames to make the rate control happy)
to something around 15. Once we are waiting for the tx status of 15 frames
we won't accept any more frames that require a tx status.

We could mark all frames that require a tx status with a unique identifier
between 0x1 and 0xf and all others with 0. The non-marked frames would be
freed from the DMA_DONE interrupt handler, while the marked frames are freed
once the tx status arrives.

As far as I could see during my tests so far this might be the only way to
really ensure that no tx status gets lost.

Any objections, or better ideas?

Thanks,
Helmut




More information about the users mailing list