Commit aec67952 authored by Jouni Malinen's avatar Jouni Malinen Committed by John W. Linville

mac80211: Comment the order of HT RX reorder handler vs. RX handlers

We are currently processing block ack reordering as a separate task
before all other RX handlers. In theory, this is wrong since this step
should be done only after duplicate removal (see Figure 6-1 in IEEE
802.11n). However, moving this needs some work and the current
situation is not too bad. Add a comment here so that this small detail
does not get forgotten and who knows, maybe someone has some extra
time to take a look at cleaning this up.
Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
parent 4d050f1d
......@@ -2551,6 +2551,18 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb,
return;
}
/*
* In theory, the block ack reordering should happen after duplicate
* removal (ieee80211_rx_h_check(), which is an RX handler). As such,
* the call to ieee80211_rx_reorder_ampdu() should really be moved to
* happen as a new RX handler between ieee80211_rx_h_check and
* ieee80211_rx_h_decrypt. This cleanup may eventually happen, but for
* the time being, the call can be here since RX reorder buf processing
* will implicitly skip duplicates. We could, in theory at least,
* process frames that ieee80211_rx_h_passive_scan would drop (e.g.,
* frames from other than operational channel), but that should not
* happen in normal networks.
*/
if (!ieee80211_rx_reorder_ampdu(local, skb, status))
__ieee80211_rx_handle_packet(hw, skb, status, rate);
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment