Trouble shooting low rate MCS9 in 802.11ac

[Ben Greear]

On 07/29/2014 08:04 AM, Vu Hai NGUYEN wrote:
>>>> I follow a tutorial to cross compile perf so here is my result
>>>>
>>>>
>>>> PerfTop:      70 irqs/sec  kernel:98.6%  exact:  0.0% [1000Hz cycles],  (all, 1 CPU)
>>>> -------------------------------------------------------------------------------
>>>>
>>>>     39.43%  [kernel]       [k] csum_partial_copy_nocheck
> 
>>> Looks like your ethernet driver is not doing checksum offloading?
> 
>>> I am pretty sure ath10k does support this unless you have managed
>>> to disabled it somehow?
> 
>> I'm using ath10k from master branch (generated by backport), My only hack is changing the default country of regulatory domain from US to France.
>> The checksum patch is implemented by Michal Kazior since july 2013 and I also check that there is function checksum state in htt_rx.c file so it should be in my
>> driver module.
>> But I install ethtool and here is the ouput of my interface wlan0:
>> #ethtool --show-offload  wlan0
>> Features for wlan0:
>> rx-checksumming: off [fixed]
>> tx-checksumming: on
>>        tx-checksum-ipv4: off [fixed]
>>        tx-checksum-unneeded: off [fixed]
>>        tx-checksum-ip-generic: on [fixed]
>>        tx-checksum-ipv6: off [fixed]
>>        tx-checksum-fcoe-crc: off [fixed]
>>        tx-checksum-sctp: off [fixed]
>> scatter-gather: off
>>        tx-scatter-gather: off [fixed]
>>        tx-scatter-gather-fraglist: off [fixed]
>> tcp-segmentation-offload: off
>>        tx-tcp-segmentation: off [fixed]
>>        tx-tcp-ecn-segmentation: off [fixed]
>>        tx-tcp6-segmentation: off [fixed]
>> udp-fragmentation-offload: off [fixed]
>> generic-segmentation-offload: off [requested on]
>> generic-receive-offload: on
>> large-receive-offload: off [fixed]
>> rx-vlan-offload: off [fixed]
>> tx-vlan-offload: off [fixed]
>> ntuple-filters: off [fixed]
>> receive-hashing: off [fixed]
>> highdma: off [fixed]
>> rx-vlan-filter: off [fixed]
>> vlan-challenged: off [fixed]
>> tx-lockless: off [fixed]
>> netns-local: on [fixed]
>> tx-gso-robust: off [fixed]
>> tx-fcoe-segmentation: off [fixed]
>> fcoe-mtu: off [fixed]
>> tx-nocache-copy: on
>> loopback: off [fixed]
>>
>> And I cannot enable these function, as it show [fixed] like above.
>> # ethtool --offload  wlan0  rx on  tx on
>> Cannot change rx-checksumming
>> Cannot change tx-checksumming
> 
> I used ethtool to disable Checksum offloading on my Ethernet interface and increase rate from
> 400 Mbps to 500 Mbps, now the thread "csum_partial_copy_nocheck" has disappeared and there
> is no more particular thread which takes most of the processor resource. But my processor is 
> always exhausted. 

Strange that disabling checksum helped things.  Maybe your ethernet driver
has issues?

Looks like removing netfilter (and maybe ebtables?) would
also help your performance...

tx status is needed for bookkeping at least, even if you don't
get useful status info in stock firmware.

CT firmware will give you proper status if you apply some of the
ath10k driver patches from my tree, but that is unlikely to help
performance.

Thanks,
Ben

> I notice some warning when starting perf top
> [ath10k_core] with build id f31b98301ddea35e320bacaef048e4adbae00a6d not found, continuing without symbols
> [ath10k_pci] with build id a1303b5587ceef676d03d5a68fa5c7d717861c5d not found, continuing without symbols
> [mac80211] with build id f73251a940dedf51ac599141e5edefe05da2cb6f not found, continuing without symbols
> [cfg80211] with build id 94dd0809b98902252ce78cc3bc4ae385dd5e8fdf not found, continuing without symbols
> This may cause some unknown thread like the 2nd thread $a below of [mac80211]?
>  
> PerfTop:      51 irqs/sec  kernel:98.0%  exact:  0.0% [1000Hz cycles],  (all, 1 CPU)
> -------------------------------------------------------------------------------
> 
>      8.79%  [mac80211]     [k] ieee80211_tx_status
>      5.02%  [mac80211]     [k] $a
>      5.02%  [kernel]       [k] __memzero
>      4.60%  [kernel]       [k] memcpy
>      4.60%  [kernel]       [k] mv_eth_poll
>      4.18%  [kernel]       [k] dev_queue_xmit
>      4.18%  [kernel]       [k] br_parse_ip_options
>      3.77%  [kernel]       [k] dev_hard_start_xmit
>      3.77%  [kernel]       [k] nf_hook_slow
>      3.35%  [kernel]       [k] local_bh_enable
>      3.35%  [kernel]       [k] nf_iterate
>      3.35%  [kernel]       [k] br_nf_forward_ip
>      2.93%  [kernel]       [k] kfree
>      2.93%  [kernel]       [k] br_nf_pre_routing
>      2.93%  [kernel]       [k] mv_eth_tx
>      2.93%  [kernel]       [k] br_handle_frame_finish
>      2.93%  [ath10k_pci]   [k] ath10k_ce_send_nolock
>      2.93%  [ath10k_core]  [k] ath10k_txrx_tx_unref
>      2.51%  [kernel]       [k] eth_type_trans
>      2.51%  [ath10k_core]  [k] ath10k_htt_rx_amsdu_pop
> 
> I notice that ieee80211_tx_status takes much of resource too, but because of firmware
> issue we don't get true information from tx_status, should we deactivate it to improve
> the performance?
> 
> NGUYEN Vu Hai
> Acita-Sodielec
> Route de Mayres - B.P. 9
> 12100 St GEORGES DE LUZENCON
> FRANCE
> 
> 
> 
> 
> NGUYEN Vu Hai
> Acita-Sodielec
> Route de Mayres - B.P. 9
> 12100 St GEORGES DE LUZENCON
> FRANCE
> 
> 
> 
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com