carl9170: remove lost-frame workaround
This patch removes some cruft, which survived the RFC review phase. Originally, carl9170_tx_ampdu_queue erroneously dropped a lot of frames. As a result the ampdu scheduler bogged down quite frequently and the affected BA session timed out. However this bug has been fixed and the WA and its debugfs counter is no longer useful. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This commit is contained in:
parent
b4c85d459c
commit
042c53f6e8
@ -364,7 +364,6 @@ struct ar9170 {
|
||||
unsigned int tx_dropped;
|
||||
unsigned int tx_ack_failures;
|
||||
unsigned int tx_fcs_errors;
|
||||
unsigned int tx_ampdu_timeout;
|
||||
unsigned int rx_dropped;
|
||||
|
||||
/* EEPROM */
|
||||
|
@ -798,8 +798,6 @@ DEBUGFS_READONLY_FILE(tx_total_queued, 20, "%d",
|
||||
atomic_read(&ar->tx_total_queued));
|
||||
DEBUGFS_READONLY_FILE(tx_ampdu_scheduler, 20, "%d",
|
||||
atomic_read(&ar->tx_ampdu_scheduler));
|
||||
DEBUGFS_READONLY_FILE(tx_ampdu_timeout, 20, "%d",
|
||||
ar->tx_ampdu_timeout);
|
||||
|
||||
DEBUGFS_READONLY_FILE(tx_total_pending, 20, "%d",
|
||||
atomic_read(&ar->tx_total_pending));
|
||||
@ -872,8 +870,6 @@ void carl9170_debugfs_register(struct ar9170 *ar)
|
||||
DEBUGFS_ADD(ampdu_density);
|
||||
DEBUGFS_ADD(ampdu_factor);
|
||||
|
||||
DEBUGFS_ADD(tx_ampdu_timeout);
|
||||
|
||||
DEBUGFS_ADD(tx_janitor_last_run);
|
||||
|
||||
DEBUGFS_ADD(tx_status_0);
|
||||
|
@ -1042,41 +1042,8 @@ retry:
|
||||
queue = TID_TO_WME_AC(tid_info->tid);
|
||||
|
||||
spin_lock_bh(&tid_info->lock);
|
||||
if (tid_info->state != CARL9170_TID_STATE_XMIT) {
|
||||
first = skb_peek(&tid_info->queue);
|
||||
if (first) {
|
||||
struct ieee80211_tx_info *txinfo;
|
||||
struct carl9170_tx_info *arinfo;
|
||||
|
||||
txinfo = IEEE80211_SKB_CB(first);
|
||||
arinfo = (void *) txinfo->rate_driver_data;
|
||||
|
||||
if (time_is_after_jiffies(arinfo->timeout +
|
||||
msecs_to_jiffies(CARL9170_QUEUE_TIMEOUT))
|
||||
== true)
|
||||
goto processed;
|
||||
|
||||
/*
|
||||
* We've been waiting for the frame which
|
||||
* matches "snx" (start sequence of the
|
||||
* next aggregate) for some time now.
|
||||
*
|
||||
* But it never arrived. Therefore
|
||||
* jump to the next available frame
|
||||
* and kick-start the transmission.
|
||||
*
|
||||
* Note: This might induce odd latency
|
||||
* spikes because the receiver will be
|
||||
* waiting for the lost frame too.
|
||||
*/
|
||||
ar->tx_ampdu_timeout++;
|
||||
|
||||
tid_info->snx = carl9170_get_seq(first);
|
||||
tid_info->state = CARL9170_TID_STATE_XMIT;
|
||||
} else {
|
||||
goto processed;
|
||||
}
|
||||
}
|
||||
if (tid_info->state != CARL9170_TID_STATE_XMIT)
|
||||
goto processed;
|
||||
|
||||
tid_info->counter++;
|
||||
first = skb_peek(&tid_info->queue);
|
||||
|
Loading…
x
Reference in New Issue
Block a user