A-MSDU reception not working?
Liu CF/TW
cfliu.tw at gmail.com
Mon Jul 7 22:58:22 PDT 2014
I wonder is it the firmware or mac80211 at AP side that handles ADDBA
requests from MacBook in this case?
- If it is mac80211, then we can try disabling AMSDU-in-AMPDU. in
agg_rx.c by setting the 'policy' argument to 0:
ieee80211_send_addba_resp(sta->sdata, sta->sta.addr, tid,
dialog_token, status, 0, buf_size, timeout);
- if it is inside the firmware, then in ath10k WMI, it seems FW does
support the following BA related commands (but alas there are no
details how these commands could be used ie. no C structure defined to
know how to fill the command)
If ADDBA req is handled by FW when AP is the recipient, I guess
WMI_10X_ADDBA_SET_RESP_CMDID could be used to disable AMSDU-in-AMPDU
during BA negotiation:
/* commands to directly control ba negotiation directly from host. */
WMI_10X_ADDBA_CLEAR_RESP_CMDID,
WMI_10X_ADDBA_SEND_CMDID,
WMI_10X_ADDBA_STATUS_CMDID,
WMI_10X_DELBA_SEND_CMDID,
WMI_10X_ADDBA_SET_RESP_CMDID,
WMI_10X_SEND_SINGLEAMSDU_CMDID,
In general, I think AMSDU-in-AMPDU shouldn't be hard coded as always
enabled in mac80211 but should be a policy. Iterating through AMSDU
subframes is not just slow on embedded CPUs, but the nature they all
share the same PN and same CRC makes it inferior to AMPDU, where MPDUs
aggregated using AMPDU could independently acknowledged, encrypted &
integrity-checked. (Although it is indeed a valid workaround to sender
larger PPDU (4Kx64=256K) since BA bitmap size hasn't been increased
since 11n)
Does anyone know more details about how WMI_10X_ADDBA_SET_RESP_CMDID
could be used?
Thanks,
cfliu
2014-07-07 12:53 GMT-07:00 Denton Gentry <denton.gentry at gmail.com>:
> I don't know of a way to tell the STA to not use A-MSDU; is there one?
> A-MSDU reception is mandatory in the specifications, it didn't look
> like there was a way to communicate that it isn't allowed.
>
> We can disable our own sending of A-MSDUs, but that isn't the issue here.
>
> With 802.11ac the minimum MPDU size appears to be 3895 bytes, which is
> big enough to hold two 1500 byte subframes. If there were a way to
> force it the MPDU size smaller that could effectively prevent the STA
> from using A-MSDU, but I don't see a way to do that either.
>
>
>
> On Mon, Jul 7, 2014 at 12:41 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>> .. why not disable AMSDU reception for now? Until these things are fixed?
>>
>>
>>
>> -a
>>
>>
>> On 7 July 2014 12:26, Denton Gentry <denton.gentry at gmail.com> wrote:
>>> The initial results are not promising: a MacOS 802.11ac client gets
>>> between 0-2 Mbps with this change, where it was getting about 8 Mbps
>>> prior to this change and ~170 Mbps prior to the reordering fix. A pcap
>>> from the receiving system shows a very large number of out of order
>>> frames, likely due to TCP retransmission.
>>>
>>> An 802.11n MacBook gets very good throughput, only the 802.11ac
>>> MacBook shows the very poor result. I'm trying to figure out why.
>>>
>>>
>>> One specific note (and probably not related to the throughput): I
>>> believe ath10k_htt_rx_amsdu runs in the tasklet, which means it would
>>> need to use GFP_ATOMIC instead of GFP_KERNEL. Do I understand it
>>> correctly?
>>>
>>>
>>> On Mon, Jul 7, 2014 at 1:30 AM, Janusz Dziedzic
>>> <janusz.dziedzic at tieto.com> wrote:
>>>> On 6 July 2014 04:27, Adrian Chadd <adrian at freebsd.org> wrote:
>>>>> I think you may have to tell mac80211 that it's okay and not to drop the frames.
>>>>>
>>>>> The earlier atheros chips would just give you the AMSDU frames as
>>>>> deaggregated A-MPDU sub-frames - you'd just pass the A-MSDU up to
>>>>> net80211 and it'd ull it apart. But if the driver is doing it (or,
>>>>> well, the chip is doing it) then mac80211 needs to know not to drop
>>>>> those sub-frames.
>>>>>
>>>>> I wonder if you'll ever get notified before the complete A-MPDU has
>>>>> been received. That happens on previous chips. eg, you have an A-MPDU
>>>>> of 16 frames with 4 MSDUs in each MPDU. If you get notified and handle
>>>>> half of one MPDU before you hit EOL, the next notification you process
>>>>> will be the next MSDU in the same MPDU - and then you'll hit the
>>>>> reordering hilarity again.
>>>>>
>>>>> So hm, i will face the same issue in FreeBSD at some point, so I'd
>>>>> likely do what you're thinking of doing - pass up a chain of mbufs
>>>>> representing the current MPDU and treat the whole lot as the frame(s)
>>>>> to care about. Honestly though, I'm kind of wondering whether I should
>>>>> mostly just do what the Atheros reference driver does and treat it as
>>>>> ethernet payload frames (ie, it's already de-encapsulated and the
>>>>> reordering is already done) and just tack on the wifi header bit via
>>>>> another of the DMA rings.
>>>>>
>>>>> Ugh, I really should sit down and write the FreeBSD version of this.
>>>>>
>>>>>
>>>>>
>>>>> -a
>>>>>
>>>>> (I'm still having flashbacks from working on this firmware at QCA. Aiee.)
>>>>>
>>>>>
>>>>> On 5 July 2014 06:55, Denton Gentry <denton.gentry at gmail.com> wrote:
>>>>>> There are two issues in handling the dis-aggregated A-MSDU subframes
>>>>>> in ieee80211_sta_manage_reorder_buf:
>>>>>>
>>>>>> 1. The out-of-date check:
>>>>>>
>>>>>> /* frame with out of date sequence number */
>>>>>> if (ieee80211_sn_less(mpdu_seq_num, head_seq_num)) {
>>>>>> dev_kfree_skb(skb);
>>>>>> goto out;
>>>>>> }
>>>>>>
>>>>>> As all of the subframes carry the same sequence number, the first
>>>>>> subframe will be delivered and increment head_seq_num and then all
>>>>>> subsequent subframes will be discarded.
>>>>>>
>>>>>>
>>>>>> 2. The duplicates check a bit later in the routine:
>>>>>>
>>>>>> /* check if we already stored this frame */
>>>>>> if (tid_agg_rx->reorder_buf[index]) {
>>>>>> dev_kfree_skb(skb);
>>>>>> goto out;
>>>>>> }
>>>>>>
>>>>>> If there is enough packet loss that packets are queued in the reorder
>>>>>> buffer and not immediately released, then only the first subframe will
>>>>>> be stored. Subsequent subframes will be discarded as duplicates.
>>>>>>
>>>>>>
>>>>>> An 802.11ac MacBook is able to get about 170 Mbps with iperf prior to
>>>>>> the reordering buffer changes, and dropped to about 8 Mbps with the
>>>>>> reorder buffer. Hacking around the out-of-date sequence number check
>>>>>> to allow all subframes to egress restores it to 170 Mbps.
>>>>>>
>>>>>> In the area where I'm testing there isn't enough 5 GHz noise to make
>>>>>> the duplicates-check issue happen very often. By adding a printk I can
>>>>>> see that it does happen, but it doesn't impact the throughput and I
>>>>>> can't report the impact of fixing it.
>>>>>>
>>>>>> ----
>>>>>>
>>>>>> I do wonder if both of these are symptoms of dis-aggregating the
>>>>>> A-MSDU too early. mac80211 expects to be dealing with the whole MPDU
>>>>>> at a time, and the ath10k A-MSDU case is sending it subframes instead.
>>>>>> Trying to make the ath10k code send up all of the subframes as a chain
>>>>>> of skbs didn't immediately work, but I do wonder if that would better
>>>>>> match the mac80211 expectations.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 4, 2014 at 11:58 AM, Denton Gentry <denton.gentry at gmail.com> wrote:
>>>>>>> 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?
>>>>>>>>
>>>> Denton could you try attached patch: report amsdu in one big frame.
>>>> If help, we can add amsdu skb list support to mac80211/cfg80211 - to
>>>> improve performance and reduce memcpy, while currently we have skb
>>>> frames, put them in one big skb and next cfg80211 split them again
>>>> into msdus and report to stack.
>>>>
>>>> BR
>>>> Janusz
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
More information about the ath10k
mailing list