2004-12-08 17:34:36 +00:00
|
|
|
/*-
|
2008-04-20 20:35:46 +00:00
|
|
|
* Copyright (c) 2004-2008 Sam Leffler, Errno Consulting
|
2004-12-08 17:34:36 +00:00
|
|
|
* Copyright (c) 2004 Video54 Technologies, Inc.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer,
|
2007-06-06 15:49:16 +00:00
|
|
|
* without modification.
|
2004-12-08 17:34:36 +00:00
|
|
|
* 2. Redistributions in binary form must reproduce at minimum a disclaimer
|
|
|
|
|
* similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
|
|
|
|
|
* redistribution must be conditioned upon including a substantially
|
|
|
|
|
* similar Disclaimer requirement for further binary redistribution.
|
|
|
|
|
*
|
|
|
|
|
* NO WARRANTY
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
|
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
|
* LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
|
|
|
|
|
* AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
|
|
|
|
|
* THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
|
|
|
|
|
* OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
|
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
|
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
|
|
|
|
|
* IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
|
|
|
|
|
* THE POSSIBILITY OF SUCH DAMAGES.
|
|
|
|
|
*
|
|
|
|
|
* $FreeBSD$
|
|
|
|
|
*/
|
|
|
|
|
#ifndef _ATH_RATECTRL_H_
|
|
|
|
|
#define _ATH_RATECTRL_H_
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Interface definitions for transmit rate control modules for the
|
|
|
|
|
* Atheros driver.
|
|
|
|
|
*
|
|
|
|
|
* A rate control module is responsible for choosing the transmit rate
|
|
|
|
|
* for each data frame. Management+control frames are always sent at
|
|
|
|
|
* a fixed rate.
|
|
|
|
|
*
|
|
|
|
|
* Only one module may be present at a time; the driver references
|
|
|
|
|
* rate control interfaces by symbol name. If multiple modules are
|
|
|
|
|
* to be supported we'll need to switch to a registration-based scheme
|
|
|
|
|
* as is currently done, for example, for authentication modules.
|
|
|
|
|
*
|
|
|
|
|
* An instance of the rate control module is attached to each device
|
|
|
|
|
* at attach time and detached when the device is destroyed. The module
|
|
|
|
|
* may associate data with each device and each node (station). Both
|
|
|
|
|
* sets of storage are opaque except for the size of the per-node storage
|
|
|
|
|
* which must be provided when the module is attached.
|
|
|
|
|
*
|
|
|
|
|
* The rate control module is notified for each state transition and
|
|
|
|
|
* station association/reassociation. Otherwise it is queried for a
|
|
|
|
|
* rate for each outgoing frame and provided status from each transmitted
|
|
|
|
|
* frame. Any ancillary processing is the responsibility of the module
|
|
|
|
|
* (e.g. if periodic processing is required then the module should setup
|
|
|
|
|
* it's own timer).
|
|
|
|
|
*
|
|
|
|
|
* In addition to the transmit rate for each frame the module must also
|
|
|
|
|
* indicate the number of attempts to make at the specified rate. If this
|
|
|
|
|
* number is != ATH_TXMAXTRY then an additional callback is made to setup
|
|
|
|
|
* additional transmit state. The rate control code is assumed to write
|
|
|
|
|
* this additional data directly to the transmit descriptor.
|
|
|
|
|
*/
|
|
|
|
|
struct ath_softc;
|
|
|
|
|
struct ath_node;
|
|
|
|
|
struct ath_desc;
|
|
|
|
|
|
|
|
|
|
struct ath_ratectrl {
|
|
|
|
|
size_t arc_space; /* space required for per-node state */
|
|
|
|
|
};
|
|
|
|
|
/*
|
|
|
|
|
* Attach/detach a rate control module.
|
|
|
|
|
*/
|
|
|
|
|
struct ath_ratectrl *ath_rate_attach(struct ath_softc *);
|
|
|
|
|
void ath_rate_detach(struct ath_ratectrl *);
|
|
|
|
|
|
2011-11-08 01:35:05 +00:00
|
|
|
#define ATH_RC_NUM 4
|
|
|
|
|
|
|
|
|
|
#define ATH_RC_DS_FLAG 0x01 /* dual-stream rate */
|
|
|
|
|
#define ATH_RC_CW40_FLAG 0x02 /* use HT40 */
|
|
|
|
|
#define ATH_RC_SGI_FLAG 0x04 /* use short-GI */
|
|
|
|
|
#define ATH_RC_HT_FLAG 0x08 /* use HT */
|
|
|
|
|
#define ATH_RC_RTSCTS_FLAG 0x10 /* enable RTS/CTS protection */
|
|
|
|
|
|
|
|
|
|
struct ath_rc_series {
|
|
|
|
|
uint8_t rix; /* ratetable index, not rate code */
|
|
|
|
|
uint8_t ratecode; /* hardware rate code */
|
|
|
|
|
uint8_t tries;
|
|
|
|
|
uint8_t flags;
|
|
|
|
|
uint32_t max4msframelen;
|
|
|
|
|
};
|
2004-12-08 17:34:36 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* State storage handling.
|
|
|
|
|
*/
|
|
|
|
|
/*
|
|
|
|
|
* Initialize per-node state already allocated for the specified
|
|
|
|
|
* node; this space can be assumed initialized to zero.
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_node_init(struct ath_softc *, struct ath_node *);
|
|
|
|
|
/*
|
|
|
|
|
* Cleanup any per-node state prior to the node being reclaimed.
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_node_cleanup(struct ath_softc *, struct ath_node *);
|
|
|
|
|
/*
|
|
|
|
|
* Update rate control state on station associate/reassociate
|
|
|
|
|
* (when operating as an ap or for nodes discovered when operating
|
|
|
|
|
* in ibss mode).
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_newassoc(struct ath_softc *, struct ath_node *,
|
|
|
|
|
int isNewAssociation);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Transmit handling.
|
|
|
|
|
*/
|
2011-02-01 08:10:18 +00:00
|
|
|
/*
|
|
|
|
|
* Return the four TX rate index and try counts for the current data packet.
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_getxtxrates(struct ath_softc *sc, struct ath_node *an,
|
Introduce TX aggregation and software TX queue management
for Atheros AR5416 and later wireless devices.
This is a very large commit - the complete history can be
found in the user/adrian/if_ath_tx branch.
Legacy (ie, pre-AR5416) devices also use the per-software
TXQ support and (in theory) can support non-aggregation
ADDBA sessions. However, the net80211 stack doesn't currently
support this.
In summary:
TX path:
* queued frames normally go onto a per-TID, per-node queue
* some special frames (eg ADDBA control frames) are thrown
directly onto the relevant hardware queue so they can
go out before any software queued frames are queued.
* Add methods to create, suspend, resume and tear down an
aggregation session.
* Add in software retransmission of both normal and aggregate
frames.
* Add in completion handling of aggregate frames, including
parsing the block ack bitmap provided by the hardware.
* Write an aggregation function which can assemble frames into
an aggregate based on the selected rate control and channel
configuration.
* The per-TID queues are locked based on their target hardware
TX queue. This matches what ath9k/atheros does, and thus
simplified porting over some of the aggregation logic.
* When doing TX aggregation, stick the sequence number allocation
in the TX path rather than net80211 TX path, and protect it
by the TXQ lock.
Rate control:
* Delay rate control selection until the frame is about to
be queued to the hardware, so retried frames can have their
rate control choices changed. Frames with a static rate
control selection have that applied before each TX, just
to simplify the TX path (ie, not have "static" and "dynamic"
rate control special cased.)
* Teach ath_rate_sample about aggregates - both completion and
errors.
* Add an EWMA for tracking what the current "good" MCS rate is
based on failure rates.
Misc:
* Introduce a bunch of dirty hacks and workarounds so TID mapping
and net80211 frame inspection can be kept out of the net80211
layer. Because of the way this code works (and it's from Atheros
and Linux ath9k), there is a consistent, 1:1 mapping between
TID and AC. So we need to ensure that frames going to a specific
TID will _always_ end up on the right AC, and vice versa, or the
completion/locking will simply get very confused. I plan on
addressing this mess in the future.
Known issues:
* There is no BAR frame transmission just yet. A whole lot of
tidying up needs to occur before BAR frame TX can occur in the
"correct" place - ie, once the TID TX queue has been drained.
* Interface reset/purge/etc results in frames in the TX and RX
queues being removed. This creates holes in the sequence numbers
being assigned and the TX/RX AMPDU code (on either side) just
hangs.
* There's no filtered frame support at the present moment, so
stations going into power saving mode will simply have a number
of frames dropped - likely resulting in a traffic "hang".
* Raw frame TX is going to just not function with 11n aggregation.
Likely this needs to be modified to always override the sequence
number if the frame is going into an aggregation session.
However, general raw frame injection currently doesn't work in
general in net80211, so let's just ignore this for now until
this is sorted out.
* HT protection is just not implemented and won't be until the above
is sorted out. In addition, the AR5416 has issues RTS protecting
large aggregates (anything >8k), so the work around needs to be
ported and tested. Thus, this will be put on hold until the above
work is complete.
* The rate control module 'sample' is the only currently supported
module; onoe/amrr haven't been tested and have likely bit rotted
a little. I'll follow up with some commits to make them work again
for non-11n rates, but they won't be updated to handle 11n and
aggregation. If someone wishes to do so then they're welcome to
send along patches.
* .. and "sample" doesn't really do a good job of 11n TX. Specifically,
the metrics used (packet TX time and failure/success rates) isn't as
useful for 11n. It's likely that it should be extended to take into
account the aggregate throughput possible and then choose a rate
which maximises that. Ie, it may be acceptable for a higher MCS rate
with a higher failure to be used if it gives a more acceptable
throughput/latency then a lower MCS rate @ a lower error rate.
Again, patches will be gratefully accepted.
Because of this, ATH_ENABLE_11N is still not enabled by default.
Sponsored by: Hobnob, Inc.
Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
|
|
|
uint8_t rix0, struct ath_rc_series *rc);
|
2011-02-01 08:10:18 +00:00
|
|
|
|
2004-12-08 17:34:36 +00:00
|
|
|
/*
|
|
|
|
|
* Return the transmit info for a data packet. If multi-rate state
|
|
|
|
|
* is to be setup then try0 should contain a value other than ATH_TXMATRY
|
|
|
|
|
* and ath_rate_setupxtxdesc will be called after deciding if the frame
|
|
|
|
|
* can be transmitted with multi-rate retry.
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_findrate(struct ath_softc *, struct ath_node *,
|
2005-04-02 18:54:30 +00:00
|
|
|
int shortPreamble, size_t frameLen,
|
2004-12-08 17:34:36 +00:00
|
|
|
u_int8_t *rix, int *try0, u_int8_t *txrate);
|
|
|
|
|
/*
|
|
|
|
|
* Setup any extended (multi-rate) descriptor state for a data packet.
|
|
|
|
|
* The rate index returned by ath_rate_findrate is passed back in.
|
|
|
|
|
*/
|
|
|
|
|
void ath_rate_setupxtxdesc(struct ath_softc *, struct ath_node *,
|
2005-04-02 18:54:30 +00:00
|
|
|
struct ath_desc *, int shortPreamble, u_int8_t rix);
|
2004-12-08 17:34:36 +00:00
|
|
|
/*
|
|
|
|
|
* Update rate control state for a packet associated with the
|
|
|
|
|
* supplied transmit descriptor. The routine is invoked both
|
|
|
|
|
* for packets that were successfully sent and for those that
|
|
|
|
|
* failed (consult the descriptor for details).
|
Introduce TX aggregation and software TX queue management
for Atheros AR5416 and later wireless devices.
This is a very large commit - the complete history can be
found in the user/adrian/if_ath_tx branch.
Legacy (ie, pre-AR5416) devices also use the per-software
TXQ support and (in theory) can support non-aggregation
ADDBA sessions. However, the net80211 stack doesn't currently
support this.
In summary:
TX path:
* queued frames normally go onto a per-TID, per-node queue
* some special frames (eg ADDBA control frames) are thrown
directly onto the relevant hardware queue so they can
go out before any software queued frames are queued.
* Add methods to create, suspend, resume and tear down an
aggregation session.
* Add in software retransmission of both normal and aggregate
frames.
* Add in completion handling of aggregate frames, including
parsing the block ack bitmap provided by the hardware.
* Write an aggregation function which can assemble frames into
an aggregate based on the selected rate control and channel
configuration.
* The per-TID queues are locked based on their target hardware
TX queue. This matches what ath9k/atheros does, and thus
simplified porting over some of the aggregation logic.
* When doing TX aggregation, stick the sequence number allocation
in the TX path rather than net80211 TX path, and protect it
by the TXQ lock.
Rate control:
* Delay rate control selection until the frame is about to
be queued to the hardware, so retried frames can have their
rate control choices changed. Frames with a static rate
control selection have that applied before each TX, just
to simplify the TX path (ie, not have "static" and "dynamic"
rate control special cased.)
* Teach ath_rate_sample about aggregates - both completion and
errors.
* Add an EWMA for tracking what the current "good" MCS rate is
based on failure rates.
Misc:
* Introduce a bunch of dirty hacks and workarounds so TID mapping
and net80211 frame inspection can be kept out of the net80211
layer. Because of the way this code works (and it's from Atheros
and Linux ath9k), there is a consistent, 1:1 mapping between
TID and AC. So we need to ensure that frames going to a specific
TID will _always_ end up on the right AC, and vice versa, or the
completion/locking will simply get very confused. I plan on
addressing this mess in the future.
Known issues:
* There is no BAR frame transmission just yet. A whole lot of
tidying up needs to occur before BAR frame TX can occur in the
"correct" place - ie, once the TID TX queue has been drained.
* Interface reset/purge/etc results in frames in the TX and RX
queues being removed. This creates holes in the sequence numbers
being assigned and the TX/RX AMPDU code (on either side) just
hangs.
* There's no filtered frame support at the present moment, so
stations going into power saving mode will simply have a number
of frames dropped - likely resulting in a traffic "hang".
* Raw frame TX is going to just not function with 11n aggregation.
Likely this needs to be modified to always override the sequence
number if the frame is going into an aggregation session.
However, general raw frame injection currently doesn't work in
general in net80211, so let's just ignore this for now until
this is sorted out.
* HT protection is just not implemented and won't be until the above
is sorted out. In addition, the AR5416 has issues RTS protecting
large aggregates (anything >8k), so the work around needs to be
ported and tested. Thus, this will be put on hold until the above
work is complete.
* The rate control module 'sample' is the only currently supported
module; onoe/amrr haven't been tested and have likely bit rotted
a little. I'll follow up with some commits to make them work again
for non-11n rates, but they won't be updated to handle 11n and
aggregation. If someone wishes to do so then they're welcome to
send along patches.
* .. and "sample" doesn't really do a good job of 11n TX. Specifically,
the metrics used (packet TX time and failure/success rates) isn't as
useful for 11n. It's likely that it should be extended to take into
account the aggregate throughput possible and then choose a rate
which maximises that. Ie, it may be acceptable for a higher MCS rate
with a higher failure to be used if it gives a more acceptable
throughput/latency then a lower MCS rate @ a lower error rate.
Again, patches will be gratefully accepted.
Because of this, ATH_ENABLE_11N is still not enabled by default.
Sponsored by: Hobnob, Inc.
Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
|
|
|
*
|
|
|
|
|
* For A-MPDU frames, nframes and nbad indicate how many frames
|
|
|
|
|
* were in the aggregate, and how many failed.
|
2004-12-08 17:34:36 +00:00
|
|
|
*/
|
2006-12-13 19:34:35 +00:00
|
|
|
struct ath_buf;
|
2004-12-08 17:34:36 +00:00
|
|
|
void ath_rate_tx_complete(struct ath_softc *, struct ath_node *,
|
Introduce TX aggregation and software TX queue management
for Atheros AR5416 and later wireless devices.
This is a very large commit - the complete history can be
found in the user/adrian/if_ath_tx branch.
Legacy (ie, pre-AR5416) devices also use the per-software
TXQ support and (in theory) can support non-aggregation
ADDBA sessions. However, the net80211 stack doesn't currently
support this.
In summary:
TX path:
* queued frames normally go onto a per-TID, per-node queue
* some special frames (eg ADDBA control frames) are thrown
directly onto the relevant hardware queue so they can
go out before any software queued frames are queued.
* Add methods to create, suspend, resume and tear down an
aggregation session.
* Add in software retransmission of both normal and aggregate
frames.
* Add in completion handling of aggregate frames, including
parsing the block ack bitmap provided by the hardware.
* Write an aggregation function which can assemble frames into
an aggregate based on the selected rate control and channel
configuration.
* The per-TID queues are locked based on their target hardware
TX queue. This matches what ath9k/atheros does, and thus
simplified porting over some of the aggregation logic.
* When doing TX aggregation, stick the sequence number allocation
in the TX path rather than net80211 TX path, and protect it
by the TXQ lock.
Rate control:
* Delay rate control selection until the frame is about to
be queued to the hardware, so retried frames can have their
rate control choices changed. Frames with a static rate
control selection have that applied before each TX, just
to simplify the TX path (ie, not have "static" and "dynamic"
rate control special cased.)
* Teach ath_rate_sample about aggregates - both completion and
errors.
* Add an EWMA for tracking what the current "good" MCS rate is
based on failure rates.
Misc:
* Introduce a bunch of dirty hacks and workarounds so TID mapping
and net80211 frame inspection can be kept out of the net80211
layer. Because of the way this code works (and it's from Atheros
and Linux ath9k), there is a consistent, 1:1 mapping between
TID and AC. So we need to ensure that frames going to a specific
TID will _always_ end up on the right AC, and vice versa, or the
completion/locking will simply get very confused. I plan on
addressing this mess in the future.
Known issues:
* There is no BAR frame transmission just yet. A whole lot of
tidying up needs to occur before BAR frame TX can occur in the
"correct" place - ie, once the TID TX queue has been drained.
* Interface reset/purge/etc results in frames in the TX and RX
queues being removed. This creates holes in the sequence numbers
being assigned and the TX/RX AMPDU code (on either side) just
hangs.
* There's no filtered frame support at the present moment, so
stations going into power saving mode will simply have a number
of frames dropped - likely resulting in a traffic "hang".
* Raw frame TX is going to just not function with 11n aggregation.
Likely this needs to be modified to always override the sequence
number if the frame is going into an aggregation session.
However, general raw frame injection currently doesn't work in
general in net80211, so let's just ignore this for now until
this is sorted out.
* HT protection is just not implemented and won't be until the above
is sorted out. In addition, the AR5416 has issues RTS protecting
large aggregates (anything >8k), so the work around needs to be
ported and tested. Thus, this will be put on hold until the above
work is complete.
* The rate control module 'sample' is the only currently supported
module; onoe/amrr haven't been tested and have likely bit rotted
a little. I'll follow up with some commits to make them work again
for non-11n rates, but they won't be updated to handle 11n and
aggregation. If someone wishes to do so then they're welcome to
send along patches.
* .. and "sample" doesn't really do a good job of 11n TX. Specifically,
the metrics used (packet TX time and failure/success rates) isn't as
useful for 11n. It's likely that it should be extended to take into
account the aggregate throughput possible and then choose a rate
which maximises that. Ie, it may be acceptable for a higher MCS rate
with a higher failure to be used if it gives a more acceptable
throughput/latency then a lower MCS rate @ a lower error rate.
Again, patches will be gratefully accepted.
Because of this, ATH_ENABLE_11N is still not enabled by default.
Sponsored by: Hobnob, Inc.
Obtained from: Linux, Atheros
2011-11-08 22:43:13 +00:00
|
|
|
const struct ath_rc_series *, const struct ath_tx_status *,
|
|
|
|
|
int pktlen, int nframes, int nbad);
|
2012-07-20 01:27:20 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Fetch the global rate control statistics.
|
|
|
|
|
*/
|
|
|
|
|
int ath_rate_fetch_stats(struct ath_softc *sc, struct ath_rateioctl *rs);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Fetch the per-node statistics.
|
|
|
|
|
*/
|
|
|
|
|
int ath_rate_fetch_node_stats(struct ath_softc *sc, struct ath_node *an,
|
|
|
|
|
struct ath_rateioctl *rs);
|
|
|
|
|
|
2004-12-08 17:34:36 +00:00
|
|
|
#endif /* _ATH_RATECTRL_H_ */
|
