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

Roman Yeryomin leroi.lists at gmail.com
Mon Feb 1 01:54:05 PST 2016

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.


More information about the ath10k mailing list