K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-08-22T06:25:01.916242Z
K 7
svn:log
V 1810
Do some reasonably major surgery to the way TX rates are calculated
and completed, as part of providing the rate control code with accurate
information about aggregate packet completions.

Since the aggregate completion function has no idea how many frames
have succeeded or failed until -after- the ath_buf list has been walked,
compared against the Blockack bitmap (and buffers have been completed),
we need to keep a variety of the state somewhere.

So we can't just pass in an ath_buf into the completion code - it has
likely already been freed before the rate update call is made.

Also, the framelength for an aggregate is the aggregate itself, not the
length of the first frame.

The specifics:

* add a 'ratecode' field to ath_rc_series, storing the ratecode decision;
* update ratecode in ath_tx_rate_fill_rcflags(), also taking into account
  whether the ath_buf has the short preamble bit set;
* modify the sample ath_tx_rate_complete() function to take a copy of the
  ath_rc_series, along with a framelength
* if a buffer doesn't have a completion handler, manually call the rate
  control code
* if a buffer -does- have a completion handler, leave calling the rate
  control code up to that.

The things to do:

* Actually teach ath_rate_sample about the packet error rate when TX'ing
  aggregates. That's next.

* Becuase the rate lookup is done before the aggregate is formed, we can't
  query the rate control code with the length of the aggregate. It's a chicken
  and egg problem - we can't form aggregates until we know what the rate
  selection is (as that's used to enforce the 4ms frame max duration) and
  delimiter density. So for now, it'll just use the size of the first frame
  in the list when making a rate decision, and I'll worry about delaying
  the rate control lookup later.

END