From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A8E1B3B29E for ; Tue, 28 Apr 2020 11:38:28 -0400 (EDT) Received: by mail-io1-xd2d.google.com with SMTP id k23so8096590ios.5 for ; Tue, 28 Apr 2020 08:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=TUmbFOw9gzmZHCX8iP/GV0ZjTIedi/M82pgMMFXxgO0=; b=gslcBmMV18XAxFtClXJS0LqhsNvpDGcFITM6rp82QuenouHdLDZXPCMJqlq997XuJi CvkND2VVMMb074d1iu2h7Ti8h4wa2cAtrYBFP7n/dTs+3tJxLtlfhmW8gr7MROuwKu09 blqAq3/Yv7cTxI9yo7Lo868H25e1rV5Rf5puFfJVpruUHHwMJJUuGVWFe7/9sAZq7eZj vs3sH+fdN/tFRxwI3ptU5dKpInYHmVlgK2HzoB462p/PZBzFlB6qI+LNYwz7miLFpMi0 9/dKwMTp57DyDkLrs4gcOZs7ZvJ6sB5BiK8SrpJOJpdfT1G/9depI0Sl+VAWni3b4JFE YNQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=TUmbFOw9gzmZHCX8iP/GV0ZjTIedi/M82pgMMFXxgO0=; b=JJwkMHIWuF5ckiXLXa7519Y6nSAPJNqwj1wsRiFYfme+DmB9ly/ySunwudpzpQglnh POIhbsunaqOR/YRtds1Y6E7SeRlvtcUg1d4NUO6JST53aRr2gKJgn5fEWIrZiniVgOMy +4nda/341rxugFW3h5F26EC+6x5ayAJIRYNhOiVvcyGpTzrxOki/a3k2/5WWJ9749GGn DNt2mb2qU/bdCjSrIO1L/R8Da6peEGDm8G530DDKvG/FISOlc18lbePSE8pG+RilNi9O 6dFVug0h2Os1CE/Fo/gk6FEJWmrfzi61tiXnwfxi81VKVQeVzP/Q5azICgvqYci4fQ1j ZT4g== X-Gm-Message-State: AGi0Pua/3Q073ZAtYdw0RJNIIPRYaaQTgNbGpC2p02VVuXDfsWVXAxAc ppYsSSjuvEce/skArBDkKAh8zjJnBH9KoWus0Y/FROAB X-Google-Smtp-Source: APiQypIMSjsmT0WmbFPn7m0WbewX0P7TtolZT4gxNJy9vNYqMqL44SRQoTdz93ZPS3SunmT6+WryLeI1vgkrUD+bgtw= X-Received: by 2002:a5d:944c:: with SMTP id x12mr26320298ior.100.1588088307893; Tue, 28 Apr 2020 08:38:27 -0700 (PDT) MIME-Version: 1.0 References: <20200427145435.13151-1-greearb@candelatech.com> <1e1664b6-1998-5a4b-67ba-09113ec8d3a7@candelatech.com> In-Reply-To: <1e1664b6-1998-5a4b-67ba-09113ec8d3a7@candelatech.com> From: Dave Taht Date: Tue, 28 Apr 2020 08:38:16 -0700 Message-ID: To: Make-Wifi-fast Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Make-wifi-fast] Fwd: [PATCH] ath10k: Restart xmit queues below low-water mark. X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 15:38:28 -0000 thoughts? ---------- Forwarded message --------- From: Ben Greear Date: Tue, Apr 28, 2020 at 7:58 AM Subject: Re: [PATCH] ath10k: Restart xmit queues below low-water mark. To: Steve deRosier , Cc: linux-wireless On 04/28/2020 07:56 AM, Steve deRosier wrote: > On Mon, Apr 27, 2020 at 7:54 AM wrote: >> >> From: Ben Greear >> >> 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. Thanks, Ben > > >> Signed-off-by: Ben Greear >> --- >> 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/wireles= s/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/wire= less/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 *h= tt) >> lockdep_assert_held(&htt->tx_lock); >> >> htt->num_pending_tx--; >> - if (htt->num_pending_tx =3D=3D htt->max_num_pending_tx - 1) >> + if ((htt->num_pending_tx <=3D (htt->max_num_pending_tx / 4)) && = htt->needs_unlock) { >> + htt->needs_unlock =3D 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 *ht= t) >> return -EBUSY; >> >> htt->num_pending_tx++; >> - if (htt->num_pending_tx =3D=3D htt->max_num_pending_tx) >> + if (htt->num_pending_tx =3D=3D htt->max_num_pending_tx) { >> + htt->needs_unlock =3D true; >> ath10k_mac_tx_lock(htt->ar, ATH10K_TX_PAUSE_Q_FULL); >> + } >> >> return 0; >> } >> -- >> 2.20.1 >> > -- Ben Greear Candela Technologies Inc http://www.candelatech.com --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729