No reorder buffer?

[Denton Gentry]

On Thu, Jun 26, 2014 at 3:28 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 24 June 2014 16:47, 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.
>
> As I've mentioned in my other mail - perhaps reordering is disabled in
> firmware under some circumstances.
>
> My suspicion is monitor vdev may be involved. It is created in
> firmware when you set ath10k interface into promisc mode (bridging
> implies that; most sniffers set promisc mode too unless told to not
> to, e.g. tcpdump -p).
>
> Can you somehow verify if you observe the reordering problem without
> bridging with ethernet (e.g. run traffic to AP w/ bridging and w/o
> bridging) ? If it's too much work then forget it :-)

Running an iperf server on my AP, to take bridging out of the picture:
iperf -s -w 1M

Using a Windows iperf client to talk to it:
iperf.exe -c 192.168.254.2 -w 1M -P 1 -i 1 -l 64K -t 10

With the unmodified ath10k (with no reorder buffer) I get 56.7 Mbps.
There is a fair degree of variability second to second, from 41 Mbps
to 76 Mbps.

With the modified driver which always allocates
sta->ampdu_mlme.tid_rx[0] I get 156 Mbps, with a much smaller degree
of variability of 152 - 161 Mbps second to second.