K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-08-21T16:27:59.134414Z
K 7
svn:log
V 1815
Begin adding some support framework needed to try and get a handle on
aggregation throughput.

The main problem at the present moment is that - at least for userspace
applications (ie iperf) generating traffic - the scheduler is called
too often (and likely calling taskqueue_enabled on each queued frame
is .. bad, I'll deal with that mistake of mine later) and thus the
software queue isn't "large" enough for aggregates to be formed.
This is noticable for UDP, where over 80% of the frames are sent
as single frames rather than being aggregated, limiting performance
on my MIPS boards to < 30mbit.

The eventual aim is to only queue enough frames to the hardware TX
queue to keep the MAC busy sending said frames, rather than filling
its TXQ with as many frames as possible. As long as packets are
queued faster than individual frames are scheduled, the software
queue will back up and give the aggregation logic something to work
with.

* Add a couple of schedule calls which kick along the TID scheduling
  after a completion handler has occured. These aren't strictly needed
  here (as the call is only needed when frames are added onto the TID
  queue) but they'll be needed later on when the TID scheduling is
  delayed to "encourage" aggregates.

* Add hwq_depth to the TID state, which tracks how many buffers are
  queued to the hardware. Aggregate buffers are (for now) counted as
  a single buffer. Since completion functions can (unfortunately)
  be called from both the ath task and when flushing/draining a queue
  (ie, from various other contexts), lock access to it.

* modify the aggregate queue function to limit scheduling aggregate
  frames based on how many hardware-queued frames from this TID are
  queued. This may flip back to being based on the hardware queue
  after some more testing.

END