K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2013-05-22T05:43:14.939284Z
K 7
svn:log
V 2708
First cut at deferred transmit for the VAP path.

The aim here is to eventually do a hybrid direct dispatch if there's no
transmitter, or a deferred dispatch if the transmitter is currently
busy.  But for now this will just have to do.  It'll add a little more
latency on top of things but it'll at least make things a bit more
sane.

* Create a new vap task for transmit
* Add transmit and qflush for the vap interface; kill the if_start()
  version of the method.
* The transmit/qflush routines still use the vap ifp if_snd queue,
  but they themselves do the packet setup, enqueue and dequeue/dispatch.
  Things are nicely separated enough to hopefully make it easier for me
  to figure out a better, flexible queue+dispatch framework.

What's next:

* Create a different taskqueue, one for each VAP, that handles transmit.
  Sticking it in the ic queue unfortunately serialises the VAP transmit
  with the ic transmit and stops multiple, overlapping VAPs from
  transmitting.  This makes things much easier but it also hides a bunch
  of potential race conditions.  So, let's break things out into a
  race-prone setup which somewhat matches the existing scenario in -HEAD -
  indepedent VAP and driver transmit threads.

* .. it may be that instead of doing per-VAP methods, we do a per-IC
  transmit taskqueue but create a separate one just for transmit.
  That way if the driver wishes to serialise its own software queue
  mechanism with the net80211 transmit path - eg because it wishes to
  allocate its own sequence numbers w/ A-MPDU - then the driver code
  can just keep the global ic vap transmit lock held, rather than trying
  to keep some per-VAP transmit lock held.

* .. and it's still not clear how to setup the TX, node (comlock) and
  driver locking in a way that isn't ugly and/or cause LORs.

* Push frames from the raw transmit path into the VAP path directly,
  rather than doing a call to ic_raw_xmit() from here.  Then the
  dispatch task can decide whether to call the vap transmit method
  or the device ic_raw_xmit method.  Serialising both of these calls
  together will go a long way towards ensuring the driver state is
  kept sane.

* Figure out how to shoehorn management traffic frame generation into
  this.  Right now it grabs the TX path lock and then sets up the
  frame state independent of the VAP transmit path.  It then calls
  ic_raw_xmit().  There's LOR problems doing it this way; it would
  just plain be nicer if we could setup these frames in the caller
  context and then assign 802.11 state (eg sequence number, tag
  with power save info, feed into FF/AMSDU/powersave/etc) state
  from inside the serialised VAP transmit path.

Anyway, still lots to do.

END