ATH10K Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: yiboz <yiboz@codeaurora.org>
Cc: erik.stromdahl@gmail.com, linux-wireless@vger.kernel.org,
	ath10k@lists.infradead.org
Subject: Re: FW: [PATCH] ath10k: fix return value check in wake_tx_q op
Date: Thu, 07 Feb 2019 16:25:15 +0200	[thread overview]
Message-ID: <87sgwz8ylw.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <66a74025a23795f305de37989c1b8aa3@codeaurora.org> (yiboz@codeaurora.org's message of "Mon, 28 Jan 2019 15:01:50 +0800")

(please don't top post)

yiboz <yiboz@codeaurora.org> writes:

> We have met performance issue on our two-core system after applying
> your patch. In WDS mode, we found that the peak throughput in TCP-DL
> and UDP-DL dropped more than 10% compared with previous one. And in
> some cases, though throughput stays the same, one CPU usage rises
> about 20% which leads to 10% in total CPU usage. With your change, I
> think driver will try its best to push as many packets as it can.
> During this time, the driver's queue lock will be held for too much
> time in one CPU and as a result, the other CPU will be blocked if it
> wants to acquired the same lock. Working in this way seems not
> efficiency.
>
> So I think it is better to revert the change till we come up with a
> new solution.

I don't think reverting is a clear option at this stage because that
again creates problems for SDIO. IIRC without this patch SDIO was
sending one packet a time (or something like that, can't remember all
the details right now).

Why does this happen only WDS mode? Did you test other modes, like AP or
client mode?

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2019-02-07 14:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-06 13:25 [PATCH] ath10k: fix return value check in wake_tx_q op Erik Stromdahl
2018-05-12  9:03 ` Kalle Valo
     [not found] ` <6dc00772b826410e930306891fd13ed9@euamsexm01f.eu.qualcomm.com>
     [not found]   ` <c77a1c0961f34ee68b7266444d2207f5@aptaiexm02e.ap.qualcomm.com>
2019-01-28  7:01     ` FW: [PATCH] " yiboz
2019-02-07 14:25       ` Kalle Valo [this message]
2019-02-25  4:40         ` Yibo Zhao
2019-03-04  1:56           ` Yibo Zhao
2019-03-11  6:44             ` Erik Stromdahl
2019-03-12  2:23               ` Yibo Zhao

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=87sgwz8ylw.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=erik.stromdahl@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=yiboz@codeaurora.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