linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wen Gong <wgong@codeaurora.org>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH v5 0/8] ath10k: improve throughout of tcp/udp TX/RX of sdio
Date: Tue, 24 Sep 2019 20:32:38 +0800	[thread overview]
Message-ID: <11062c4e1659ac759cb73af7d46a6db2@codeaurora.org> (raw)
In-Reply-To: <87sgon8inp.fsf@codeaurora.org>

On 2019-09-23 17:29, Kalle Valo wrote:
> Wen Gong <wgong@codeaurora.org> writes:
> 
>> The bottleneck of throughout on sdio chip is the bus bandwidth, to the
>> patches are all to increase the use ratio of sdio bus.
>> 
>>                       udp-rx    udp-tx    tcp-rx    tcp-tx
>> without patches(Mbps)  320        180       170       151
>> with patches(Mbps)     450        410       400       320
>> 
>> These patches only affect sdio bus chip, explanation is mentioned in 
>> each
>> patch's commit log.
> 
> Below is my summary of the patchset. I recommend splitting these into
> smaller sets, makes it a lot easier to review and apply. And please 
> send
> only one or two patchsets at a time.
> 
> [PATCH v5 1/8] ath10k: adjust skb length in ath10k_sdio_mbox_rx_packet
> 
> Applied.
> 
> Patchset 1:
> 
> [PATCH v5 2/8] ath10k: enable RX bundle receive for sdio
> [PATCH v5 3/8] ath10k: change max RX bundle size from 8 to 32 for sdio
> 
> Reasonal but needs some cleanup.
[PATCH v5 2/8] I will use sk_buff_head to replace the 
ath10k_sdio_rx_request, then it will be simple
[PATCH v5 3/8] FIELD_GET is to >>, not <<, so << still need by my 
understand
> 
> Patchset 2:
> 
> [PATCH v5 4/8] ath10k: add workqueue for RX path of sdio
> 
> Is really another thread needed? We already have one for SDIO.

the SDIO thread is used for async tx, this queue is for RX, and it will 
improve udp rx
from 200Mbps to 400Mbps. And it used the workqueue_aux of ar, not new 
created.
this patch is better to put to Patchset 1, it helps RX, so it should put 
together with the
[PATCH v5 2/8] ath10k: enable RX bundle receive for sdio

> 
> [PATCH v5 6/8] ath10k: add htt TX bundle for sdio
> 
> And again a new thread so that we would have three threads for SDIO? 
> I'm
> not convinced about that.
The thread is for tx complete indication and the thread only used for tx 
bundle, if it does not have
heavy traffic, then it will not bundle, then the thread will not run.
for bundled tx, after bundled, it has max 32 packets in each bundle, the 
tx complete for the 32 packets will cost much time, if not give the tx 
complete task to the thread, then it will much delay the bundle of the 
next packets, then it will drop throughput.
> 
> Patchset 3:
> 
> [PATCH v5 7/8] ath10k: enable alt data of TX path for sdio
> 
> Again another module parameter?
the alt_data could be removed
> 
> [PATCH v5 8/8] ath10k: enable napi on RX path for sdio
> 
> Seems reasonable, but worried about breaking USB.
it can change to check napi enabled, if not, will use old 
ieee80211_rx_ni in ath10k_htt_rx_proc_rx_ind_hl
> 
> Patchset 4:
> 
> [PATCH v5 5/8] ath10k: disable TX complete indication of htt for sdio
> 
> Quite hackish and I need numbers how much it really improves throughput
it will improve throughput,
for udp tx, it can arrive to 400Mbps, if remove this patch, it will drop 
to
130M. it not only remove the tx complete message's bus bandwidth of 
sdio, and it also
has a improvement in firmware's tx path's logic, it will change the 
logic
of tx simple both in firmware and ath10k and faster the tx circle.
And the paramter disable_tx_comp can be removed.
this patch shoud be put in Patchset 2, it help TX, so it is better to 
put together with the
[PATCH v5 6/8] ath10k: add htt TX bundle for sdio.



  reply	other threads:[~2019-09-24 12:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-05 10:38 [PATCH v5 0/8] ath10k: improve throughout of tcp/udp TX/RX of sdio Wen Gong
2019-09-05 10:38 ` [PATCH v5 1/8] ath10k: adjust skb length in ath10k_sdio_mbox_rx_packet Wen Gong
2019-09-12 13:46   ` Kalle Valo
2019-09-12 14:02     ` Nicolas Boichat
2019-09-12 14:54   ` Kalle Valo
2019-09-05 10:38 ` [PATCH v5 2/8] ath10k: enable RX bundle receive for sdio Wen Gong
2019-09-21 12:15   ` Kalle Valo
2019-09-05 10:38 ` [PATCH v5 3/8] ath10k: change max RX bundle size from 8 to 32 " Wen Gong
2019-09-23  9:05   ` Kalle Valo
2019-09-24  9:32     ` Wen Gong
2019-09-05 10:38 ` [PATCH v5 4/8] ath10k: add workqueue for RX path of sdio Wen Gong
2019-09-23  9:49   ` Kalle Valo
2019-09-05 10:38 ` [PATCH v5 5/8] ath10k: disable TX complete indication of htt for sdio Wen Gong
2019-09-21 12:02   ` Kalle Valo
2019-09-05 10:38 ` [PATCH v5 6/8] ath10k: add htt TX bundle " Wen Gong
2019-09-05 10:38 ` [PATCH v5 7/8] ath10k: enable alt data of TX path " Wen Gong
2019-09-05 10:38 ` [PATCH v5 8/8] ath10k: enable napi on RX " Wen Gong
2019-09-23  9:22   ` Kalle Valo
2019-09-12 15:39 ` [PATCH v5 0/8] ath10k: improve throughout of tcp/udp TX/RX of sdio Kalle Valo
2019-09-12 17:51   ` Kalle Valo
2019-09-13  3:54     ` Wen Gong
2019-09-20 12:44       ` Kalle Valo
2019-09-23  9:29 ` Kalle Valo
2019-09-24 12:32   ` Wen Gong [this message]
2019-09-26  2:33     ` Wen Gong
2019-10-14 11:53       ` Wen Gong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11062c4e1659ac759cb73af7d46a6db2@codeaurora.org \
    --to=wgong@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).