On 1 February 2016 at 14:35, Roman Yeryomin <[email protected]> wrote: > On 1 February 2016 at 11:54, Roman Yeryomin <[email protected]> wrote: >> On 31 January 2016 at 16:23, Manoharan, Rajkumar >> <[email protected]> wrote: >>>>On 31 January 2016 at 08:31, Manoharan, Rajkumar >>>><[email protected]> 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 _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
