Hi Ron,
> This patch handles the reordering of the Rx A-MPDU.
> This issue occurs when the sequence of the internal MPDUs is not in the
> right order. such a case can be encountered for example when some MPDUs from
> previous aggregations were recieved, while others failed, so current A-MPDU
> will contain a mix of re-transmited MPDUs and new ones.
I thought about this a bit more, here's a counter-proposal. :)
Your current patch means that when a monitor mode interface is up, it
will receive frames twice because the A-MPDU frames have already passed
__ieee80211_rx() when they were sent up by the hardware, and that copies
the frame to the monitor first thing. Also, what you're doing means that
the frame is accounted for channel load twice (yeah, I know, the stats
there suck... but still...)
What we'd really want I think is to
(1) put the frame to monitor regularly [indicating A-MPDU in the
radiotap header, this will need radiotap standard work, so not now]
(2) "keep" the frame in the ieee80211_rx_h_reorder_ampdu rx-pre-handler
(3) "release" the frame with an appropriate status later
Hence, I think it'd be best to first reorganise the current code:
(1) split __ieee80211_rx() right after the pre handler invocation and
call e.g. __ieee80211_rx_handlers() which contains all the code
from "if (sta && !(sta->flags & (WLAN_STA_WDS | WLAN_STA_ASSOC_AP"
to "} else dev_kfree_skb(skb);"
The function would have certain requirements like a filled
ieee80211_txrx_data and running under rcu_read_lock().
(2) then, you don't need status.ordered but can drop the frame right
away or pass it to __ieee80211_rx_handlers().
That way, we guarantee that each frame only passes through the complete
RX path once and your dropping the unordered frames is equivalent to the
reorder_ampdu handler having an oracle that tells it which frames to
drop and which to keep :)
Comments?
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
