[PATCH v2 0/7] ath10k: add copy engine fast path support

[Roman Yeryomin]

On 1 February 2016 at 14:35, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> On 1 February 2016 at 11:54, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>> On 31 January 2016 at 16:23, Manoharan, Rajkumar
>> <rmanohar at qti.qualcomm.com> wrote:
>>>>On 31 January 2016 at 08:31, Manoharan, Rajkumar
>>>><rmanohar at qti.qualcomm.com> wrote:
>>>>>>> Below patchset adds fast path support for uplink traffic by bypassing
>>>>>>> HTC layer processing. This is enabled by making use of unused copy
>>>>>>> engine 5 to receive HTT messages directly from HIF layer. From initial
>>>>>>> validation in VHT80/5G mode TCP UL is improved to 900Mbps from ~840Mbps
>>>>>>> in conducted test.
>>>>>>>
>>>>>>
>>>>>>Hi Rajkumar,
>>>>>>
>>>>>>I'm very curious what hardware did you use to do the tests?
>>>>>>Because with Dragonfly+Peregrine 3x3 I'm able to get only ~550Mbps :(
>>>>>>
>>>>>
>>>>> Roman,
>>>>>
>>>>> It is verified in AP148 platform which IPQ8064 (1.4GHz dual core) platform.
>>>>> Throughput will be lower in low end systems like AP135 (unicore processor).
>>>>
>>>> OK, but QSDK built with proprietary driver can reach 800Mbps at least.
>>>> 900/800 Mbps difference is fine (ethernet software bridging is >900,
>>>> e.g.) but 900/550 Mbps difference is not fine, there must be something
>>>> ath10k is not doing or doing in a wrong way.
>>>
>>> While ago, Michal did an experiments to improve performance by offloading
>>> encap/decap to firmware. Can you try with below patch set? I hope there might
>>> be some conflicts since the change is outdated. Please make sure to enable
>>> CONFIG_ATH10K_802_3_FORMAT switch.
>>>
>>> http://lists.infradead.org/pipermail/ath10k/2014-December/003935.html
>>>
>>> In one of my experiments, replacing netif_receive_skb to netif_rx in mac80211/rx.c
>>> had improved rx performance in AP135. I dont have data right now. Can you give a try?
>>
>> After quick testing with 2x2 system I didn't see any significant improvement.
>> Will test on 3x3 little bit later.
>
> 3x3 didn't perform better either. That's with 4.4 and backports from 2016-01-10.
> One weird thing I see is about 15% idle cpu.
> Any ideas?

Looks like one of the bottlenecks was in rx ring size of ethernet
driver. There is a switch (on ap152) and it looks like it gives large
bursts of packets which SoC's gmac cannot handle with short rx rings
and (relatively) slow wifi tx path.
Now I can get 700Mbps with 3x3 and still see up to 5% cpu idle. Much
better but not as good as proprietary driver.
Any ideas how to improve it further?

Regards,
Roman