All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Ben Greear <greearb@candelatech.com>,
	Steve deRosier <derosier@gmail.com>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] ath10k: Restart xmit queues below low-water mark.
Date: Tue, 28 Apr 2020 12:39:50 -0700	[thread overview]
Message-ID: <CAA93jw7exafEx3YkvR5uaaBm5kxzYp3nw14zMfgT=2SwUjaQFg@mail.gmail.com> (raw)
In-Reply-To: <87k11zv1ux.fsf@toke.dk>

On Tue, Apr 28, 2020 at 12:37 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Ben Greear <greearb@candelatech.com> writes:
>
> > On 04/28/2020 07:56 AM, Steve deRosier wrote:
> >> On Mon, Apr 27, 2020 at 7:54 AM <greearb@candelatech.com> wrote:
> >>>
> >>> From: Ben Greear <greearb@candelatech.com>
> >>>
> >>> While running tcp upload + download tests with ~200
> >>> concurrent TCP streams, 1-2 processes, and 30 station
> >>> vdevs, I noticed that the __ieee80211_stop_queue was taking
> >>> around 20% of the CPU according to perf-top, which other locking
> >>> taking an additional ~15%.
> >>>
> >>> I believe the issue is that the ath10k driver would unlock the
> >>> txqueue when a single frame could be transmitted, instead of
> >>> waiting for a low water mark.
> >>>
> >>> So, this patch adds a low-water mark that is 1/4 of the total
> >>> tx buffers allowed.
> >>>
> >>> This appears to resolve the performance problem that I saw.
> >>>
> >>> Tested with recent wave-1 ath10k-ct firmware.
> >>>
> >>
> >> Hey Ben,
> >>
> >> Did you do any testing with this patch around latency?  The nature of
> >> the thing that you fixed makes me wonder if it was intentional with
> >> respect to making WiFi fast - ie getting rid of buffers as much as
> >> possible.  Obviously the CPU impact is likely to be an unintended
> >> consequence. In any case, I don't know anything for sure, it was just
> >> a thought that went through my head when reading this.
> >
> > I did not, but on average my patch should make the queues be less full,
> > so I doubt it will hurt latency.
>
> I would tend to agree with that.

Well, I don't, as it's dependent on right sizing the ring in the first place.

But testing is in order! :)

> -Toke
>
> >>> Signed-off-by: Ben Greear <greearb@candelatech.com>
> >>> ---
> >>>  drivers/net/wireless/ath/ath10k/htt.h    | 1 +
> >>>  drivers/net/wireless/ath/ath10k/htt_tx.c | 8 ++++++--
> >>>  2 files changed, 7 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
> >>> index 31c4ddbf45cb..b5634781c0dc 100644
> >>> --- a/drivers/net/wireless/ath/ath10k/htt.h
> >>> +++ b/drivers/net/wireless/ath/ath10k/htt.h
> >>> @@ -1941,6 +1941,7 @@ struct ath10k_htt {
> >>>
> >>>         u8 target_version_major;
> >>>         u8 target_version_minor;
> >>> +       bool needs_unlock;
> >>>         struct completion target_version_received;
> >>>         u8 max_num_amsdu;
> >>>         u8 max_num_ampdu;
> >>> diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
> >>> index 9b3c3b080e92..44795d9a7c0c 100644
> >>> --- a/drivers/net/wireless/ath/ath10k/htt_tx.c
> >>> +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
> >>> @@ -145,8 +145,10 @@ void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt)
> >>>         lockdep_assert_held(&htt->tx_lock);
> >>>
> >>>         htt->num_pending_tx--;
> >>> -       if (htt->num_pending_tx == htt->max_num_pending_tx - 1)
> >>> +       if ((htt->num_pending_tx <= (htt->max_num_pending_tx / 4)) && htt->needs_unlock) {
> >>> +               htt->needs_unlock = false;
> >>>                 ath10k_mac_tx_unlock(htt->ar, ATH10K_TX_PAUSE_Q_FULL);
> >>> +       }
> >>>  }
> >>>
> >>>  int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt)
> >>> @@ -157,8 +159,10 @@ int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt)
> >>>                 return -EBUSY;
> >>>
> >>>         htt->num_pending_tx++;
> >>> -       if (htt->num_pending_tx == htt->max_num_pending_tx)
> >>> +       if (htt->num_pending_tx == htt->max_num_pending_tx) {
> >>> +               htt->needs_unlock = true;
> >>>                 ath10k_mac_tx_lock(htt->ar, ATH10K_TX_PAUSE_Q_FULL);
> >>> +       }
> >>>
> >>>         return 0;
> >>>  }
> >>> --
> >>> 2.20.1
> >>>
> >>
> >
> > --
> > Ben Greear <greearb@candelatech.com>
> > Candela Technologies Inc  http://www.candelatech.com



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729

  reply	other threads:[~2020-04-28 19:40 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 14:54 [PATCH] ath10k: Restart xmit queues below low-water mark greearb
2020-04-28 14:56 ` Steve deRosier
2020-04-28 14:58   ` Ben Greear
2020-04-28 19:36     ` Toke Høiland-Jørgensen
2020-04-28 19:39       ` Dave Taht [this message]
2020-04-28 20:00         ` Ben Greear
2020-04-28 20:58           ` Toke Høiland-Jørgensen
2020-04-28 21:23             ` Steve deRosier
2020-04-28 16:27   ` Dave Taht
2020-04-28 16:35     ` Ben Greear
2020-04-28 17:10       ` Dave Taht
2020-04-28 19:43       ` Toke Høiland-Jørgensen
2020-04-28 19:37 ` Toke Høiland-Jørgensen
2020-04-28 19:51   ` Ben Greear
2020-04-28 20:39     ` Toke Høiland-Jørgensen
2020-04-28 21:18       ` Ben Greear
2020-04-29  9:28         ` Toke Høiland-Jørgensen
2020-04-29 13:54           ` Ben Greear
2020-04-29 14:56             ` Toke Høiland-Jørgensen
2020-04-29 15:26               ` Ben Greear
2020-04-29 15:42                 ` Toke Høiland-Jørgensen
2020-04-30 23:31       ` John Deere
2020-05-01  2:16         ` Ben Greear
2020-05-01 15:50           ` John Deere
2020-05-01 17:51             ` Mark Baker
2020-05-02  5:49               ` John Deere
2020-05-02 15:56                 ` Ben Greear

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='CAA93jw7exafEx3YkvR5uaaBm5kxzYp3nw14zMfgT=2SwUjaQFg@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=derosier@gmail.com \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=toke@toke.dk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.