Need to get msdu-chaining working.

[Michal Kazior]

On 5 March 2014 21:50, Ben Greear <greearb at candelatech.com> wrote:
> On 03/05/2014 12:09 AM, Michal Kazior wrote:
>
>> Incorrect. There's actually quite a lot of amsdu with vanilla firmware
>> (keep in mind I refer to nwifi rx). In the early days ath10k was
>> stiching msdus back just to be teared down again in mac80211 and this
>> was hitting performance.
>
> I guess with native wifi you do not see any chained amsdu
> frames at ath10k now?  Out of curiosity, how do amsdu frames appear
> in ath10k?  Does the firmware take care of everything
> before it ever gets to the host for native wifi?

For nwifi amsdu you get linked skbuffs. Each skbuff is a 802.11
non-qos data frame. ath10k fixes the header (using decapped header in
rx_hdr_status) and submits each subframe separately as an independent
802.11 frame. This required a small change to be done in mac80211
(RX_FLAG_AMSDU_MORE) because all subframes share the same sequence
number and it conflicted with retransmission/deduplication
countermeasures.


>>> What throughputs are you seeing, and what NICs are you using for AP
>>> and stations?
>>
>> With current master branch CUS223-CUS223 should get over 800mbps in
>> udp tx/rx and 700mbps in tcp tx/rx with cabled setup on a poor AP135.
>> Since AP135's CPU doesn't have any time to idle around I expect x86 to
>> perform better and I don't think OTA should be terribly slower in a
>> reasonably clean environment.
>
> Over-the-air, CUS223 wasn't any better than WLE900VX, so probably not
> an issue with the NICs.  Arranging the antennas a bit gave me a bit of
> a boost, but still only around 600Mbps TCP upload, and download was
> still in the 400Mbps range.  There are no APs in scan range in the
> lower end of 5Ghz where I am running, so it should be pretty clean.
>
> I cabled WLE900VX NICs up with 30dB attenuation, and I do see about 800Mbps
> UDP upload, 700Mbps TCP upload, and 460Mbps TCP download.  Download still
> sucks compared to upload for me.
>
> I switched functions:  AP logic moved to STA machine, vice-versa.
> The mis-match between upload follows the stations/APs, not the hardware.
>
> (In this test, both machines are using stock 467.1-1 firmware.)
>
> Maybe something with how I am configuring APs interfaces is the problem.
>
> Can you verify that you see similar upload and download speeds for your
> test scenario?

I'm busy so I can't investigate this much, sorry.

Like I mentioned in my other mail - on AP135 UDP is 800mbps, TCP is
700mbps, both ways, and the bottleneck is AP135's CPU (MIPS 74Kc @
720MHz).

You might try to change your qdiscs to pfifo and check if it makes any
difference for you.


> Also, at 800Mbps UDP, perf top main offender is a 17% raw spin lock,
> but in general my system was not working too hard as far as I can tell.

To be honest I haven't tested x86-x86 performance for some time now.
I've been mainly focused on AP135. It bottlenecks elsewhere (it is
non-preemptive so spinlocks work completely different).


Michał