A-MSDU reception not working?

[Denton Gentry]

Yes, after some more testing it does look like an unfortunate
interaction between the reorder buffer and A-MSDU. The disaggregated
subframes all carry the same sequence number. The first subframe is
released from the reorder buffer and increments the head_seq_num.
Subsequent subframes are all discarded as being out of date.

[  308.514021] ieee80211_sta_manage_reorder_buf: out of date seq=0xb05
head=0xb06
[  308.520577] ieee80211_sta_manage_reorder_buf: out of date seq=0xb0a
head=0xb0b
[  308.527198] ieee80211_sta_manage_reorder_buf: out of date seq=0xb0f
head=0xb10
[  308.533857] ieee80211_sta_manage_reorder_buf: out of date seq=0xb14
head=0xb15
[  308.540480] ieee80211_sta_manage_reorder_buf: out of date seq=0xb19
head=0xb1a
[  308.547730] ieee80211_sta_manage_reorder_buf: out of date seq=0xb1e
head=0xb1f
[  308.554069] ieee80211_sta_manage_reorder_buf: out of date seq=0xb23
head=0xb24


On Wed, Jul 2, 2014 at 9:49 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
> On 30 June 2014 22:15, Denton Gentry <denton.gentry at gmail.com> wrote:
>> In iperf tests using a MacBook STA bridging through an ath10k AP to an
>> Ethernet server, I'm noticing very selective packet loss. The second
>> and subsequent frames in an A-MSDU packet appear to be dropped.
>>
>> The AP sets the A-MSDU size to 3839 bytes, and the MacBook frequently
>> sends A-MSDU packets containing two TCP frames. So far as I can tell,
>> the first TCP frame from an A-MSDU aggregate is delivered and the
>> second is consistently lost. The MacBook generally retransmits the
>> lost frame as a singleton with no aggregation, and the retransmitted
>> frame makes it through.
>>
>> This became more noticeable after the reordering fixes in
>> http://lists.infradead.org/pipermail/ath10k/2014-June/002552.html
>>
>> I see this A-MSDU packet loss behavior both with and without the
>> reordering fixes, the first packet in an A-MSDU is delivered while the
>> second is dropped. However, *without* the reordering fixes (and
>> therefore with packets delivered out of order) the MacBook sends
>> relatively few A-MSDU frames. *With* the reordering fixes, so all
>> packets are delivered in order, the MacBook keeps sending A-MSDU and
>> therefore has to deal with more packet loss. I suspect it is an
>> interaction with the MacOS TCP congestion window which I'm likely
>> never going to fully understand, its stuck in a region of the
>> congestion window where the Wifi driver keeps choosing to using
>> A-MSDU.
>
> I was actually worried about A-MSDU once A-MPDU re-ordering issue was raised.
>
> ath10k fw reports A-MSDU subframes separately. To avoid memory
> copying/allocation overhead each subframe is reported as a singly
> A-MSDU MSDU to mac80211 with an extra rx_flag AMSDU_MORE. Perhaps
> A-MPDU reordering intereferes with A-MSDU now?
>
>
> Michał