[PATCH v3] ath10k: fix Rx aggregation reordering

[Michal Kazior]

On 22 July 2014 20:37, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> (dropping linux-wireless)
>
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> Firmware doesn't perform Rx reordering so it is
>> left to the host driver to do that.
>>
>> Use mac80211 to perform reordering instead of
>> re-inventing the wheel.
>>
>> This fixes TCP throughput issues in some
>> environments.
>>
>> Reported-by: Denton Gentry <denton.gentry at gmail.com>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>> ---
>> This depends on:
>>
>>  * mac80211: fix Rx reordering with RX_FLAG_AMSDU_MORE
>>  * mac80211: add support for Rx reordering offloading
>>
>> I'm still seeing some issues with TCP traffic.
>> Apparently firmware/hardware sometimes stalls Rx
>> for ~100ms and misses some aggregate frames. I
>> wasn't able to pinpoint what the problem is. The
>> more parallel TCP streams (iperf) the more often
>> stalls happen. UDP doesn't seem to trigger the Rx
>> stalls at all.
>
> The mac80211 patches are in mac80211-next, but I can only apply this one
> only once they are in wireless-next.
>
> Also the other thing is that 3.17 merge window is very close. I might be
> able to squeeze this in but there's the risk that this patch hasn't
> received enough testing from being in ath.git. How safe (or risky) is
> this patch? If we push this to 3.17, we could try to fix regressions in
> -rc releases but that's always more difficult than waiting for 3.18.

I think it should be fairly safe. The stalls I've observed don't make
it worse than it is without Rx reordering.

But! I need to re-spin this patch since there's an endianess bug with
info0 being treated as __le32 while its __le16.


Michał