No reorder buffer?

[Denton Gentry]

Following up: to confirm or disprove whether the lack of a reorder
buffer is a factor in abnormally low throughput from Windows STAs, I
hacked sta_info_alloc() to allocate sta->ampdu_mlme.tid_rx[0] directly
instead of allocating it when processing an AddBA from the STA.

Throughput from a Windows system running iperf went up from ~45 Mbps
to 230 Mbps. A pcap collected by the Ethernet system at the other end
of the test no longer shows frames delivered out of order.

I suspect a proper fix would involve having the firmware pass the
AddBA up to the host.


On Tue, Jun 24, 2014 at 7:47 AM, Denton Gentry <denton.gentry at gmail.com> wrote:
> I'm bridging ath10k to Ethernet, gathering pcaps on another ath10k
> system in monitor mode and on the Ethernet system which is receiving
> the packets. I see packets being delivered out of order to the
> Ethernet system. So far as I can tell, any packet which has to be
> re-sent on the Wifi link will be delivered out of order to Ethernet.
>
> I believe this happens because there is no reorder buffer.
> ieee80211_rx_reorder_ampdu returns because tid_agg_rx[tid] is NULL.
>
> I believe there is no reorder buffer because
> ieee80211_process_addba_request is not being called.
> ieee80211_process_addba_request would allocate tid_agg_rx[tid].
>
> I believe ieee80211_process_addba_request is not being called because
> the firmware processes the AddBA and does not pass it up. This is the
> part I am least sure about.
>
>
> Can anyone confirm or deny that this is correct: does the firmware
> process the AddBA, but not have a reorder buffer in the firmware?
>
>
> This is noticeable mostly because of Windows. The Windows TCP stack
> seems to react more strongly to packet reordering (inferred via SACKs,
> I guess), and slows down.