Rework rt2661 TX interrupts processing
authorSepherosa Ziehau <sephe@dragonflybsd.org>
Mon, 20 Nov 2006 15:03:26 +0000 (15:03 +0000)
committerSepherosa Ziehau <sephe@dragonflybsd.org>
Mon, 20 Nov 2006 15:03:26 +0000 (15:03 +0000)
commit9dd87f8a6f730e54dfa4f21f3d9fae6a615b1908
tree964b2fecb12837118034c3d4d9640c7c53d2fb46
parent7c099e1555aa17a6284dba26a8d6fdd954fcbe7c
Rework rt2661 TX interrupts processing

The Clues: [1]
"TX DMA Done Interrupt":
A frame has been DMAed to ASIC, probably stored in an ASIC internal
TX FIFO.  The TX descriptor and the resource in host memory are useless
to ASIC

"TX Done Interrupt":
The transfering of a frame, which probably is from ASIC internal TX
FIFO, is done by ASIC, and the information concerning this transfering
is available

The Problems:
- The original driver reduces TX ring occupation counter on "TX Done
  Interrupt", though TX descriptors and related resources are already
  reaped on "TX DMA Done Interrupt"
- For some (maybe all ;-) ASIC, "TX Done Interrupt" comes less frequent
  than "TX DMA Done Interrupt", probably due to the "ASIC internal TX
  FIFO", or just because it is not intended to be used in the original
  driver's way ;-)

So useless TX descriptors slowly occupy TX ring and result in an almost
full TX ring at the most of the time if new frames keep coming at high
rate (e.g. during a long time scp(1))

The Fixes:
- Move rate control context out of rt2661_tx_data, so it is not 1:1 mapping
  with TX descriptor.  This degenerates rt2661_tx_data to rt2661_rx_data,
  so merge them and rename the new structure rt2661_data
- Add a rate control context queue, which temporarily holds rate control
  contexts for each data transfering
- Allocate the rate control context on fly during rt2661_tx_data().  Since
  this context is allocated using M_NOWAIT, it is possible that the
  alloctation fails.  if this happens, later rate control information will
  not be gathered (I think this is acceptable :-) and the reference to the
  ieee80211_node is freed immediately at the end of rt2661_tx_data().

After above three changes reaping of TX descriptors and related resources no
longer needs to be synchronized with rate control information gathering.

- Change the meaning of rt2661_tx_desc.qid, it now indicates whether rate
  control information needs to be gathered (it is not necessary at all for
  control/management frames)
- On "TX DMA Done Interrupt" instead of on "TX Done Interrupt", if some TX
  descriptors and related resources are reaped, reduce TX ring occupation
  counter, and kick ifnet.if_start

As of this commit, my Edimax EW-7608PG can tranfer data stably [2] without
being choked half way.

#
# [1] These clues are infered from a comment concering TX descriptor
#     structure in Linux RT61 driver
# [2] Though data tranfering is quite stable, its performance is still
#     far from expectation.  In infrastructured mode, 3 meters away from
#     the AP, I only got 6Mbits/s - 7Mbits/s, but under the same conditions
#     receiving performance is quite OK (~20Mbits/s)
#
sys/dev/netif/ral/rt2661.c
sys/dev/netif/ral/rt2661var.h