From patchwork Mon May 16 03:57:54 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rajkumar Manoharan X-Patchwork-Id: 9098291 X-Patchwork-Delegate: kvalo@adurom.com Return-Path: X-Original-To: patchwork-ath10k@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 917739F30C for ; Mon, 16 May 2016 03:58:45 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A04A1201F5 for ; Mon, 16 May 2016 03:58:44 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7B18220155 for ; Mon, 16 May 2016 03:58:43 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1b29ff-0007Rf-QN; Mon, 16 May 2016 03:58:19 +0000 Received: from smtp.codeaurora.org ([198.145.29.96]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1b29fd-0007OR-Ip for ath10k@lists.infradead.org; Mon, 16 May 2016 03:58:18 +0000 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 74A70613A9; Mon, 16 May 2016 03:57:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from mail.codeaurora.org (localhost [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 4BF9E6124A; Mon, 16 May 2016 03:57:54 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 16 May 2016 09:27:54 +0530 From: Rajkumar Manoharan To: Roman Yeryomin Subject: Re: ath10k performance, master branch from 20160407 In-Reply-To: References: <1460129643950.46282@qti.qualcomm.com> <1460174525702.66744@qti.qualcomm.com> <1460905574286.42282@qti.qualcomm.com> <87k2jtk3wt.fsf@kamboji.qca.qualcomm.com> Message-ID: <64e989f9150dadda9f02e6c2e728552a@codeaurora.org> X-Sender: rmanohar@codeaurora.org User-Agent: Roundcube Webmail/1.1.4 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160515_205817_698643_D5E1F39F X-CRM114-Status: GOOD ( 15.56 ) X-Spam-Score: -3.3 (---) X-BeenThere: ath10k@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Valo, Kalle" , Michal Kazior , ath10k@lists.infradead.org, "Manoharan, Rajkumar" Sender: "ath10k" Errors-To: ath10k-bounces+patchwork-ath10k=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On 2016-05-16 04:29, Roman Yeryomin wrote: > On 9 May 2016 at 15:26, Michal Kazior wrote: >> Hi Roman, >> >> On 22 April 2016 at 19:05, Roman Yeryomin >> wrote: >>> On 19 April 2016 at 18:35, Valo, Kalle >>> wrote: >>>> Michal Kazior writes: >>>> >>>>> On 19 April 2016 at 09:31, Roman Yeryomin >>>>> wrote: >>>>>> On 19 April 2016 at 08:28, Michal Kazior >>>>>> wrote: >>>>>> >>>>>>> If my hunch is right there's no easy (and proper) fix for that >>>>>>> now. >>>>>>> >>>>>>> One of the patchset patches (ath10k: implement wake_tx_queue) >>>>>>> starts >>>>>>> to use mac80211 software queuing. This introduces extra induced >>>>>>> latency and I'm guessing it results in fill-in-then-drain >>>>>>> sequences in >>>>>>> some cases which end up being long enough to make fq_codel_drop >>>>>>> more >>>>>>> work than normal. >>>>>>> >>>>>>> This is required for other changes and MU-MIMO performance >>>>>>> improvements so this patch can't be removed. >>>>>> >>>>>> But qca988x doesn't support MU-MIMO, AFAIK. >>>>> >>>>> Correct. >>>>> >>>>> >>>>>> Can this be made chip dependent? >>>>> >>>>> I guess it could but it'd arguably make the driver more complex and >>>>> harder to maintain. What we want is a long-term fix, not a >>>>> short-term >>>>> one. >>>> >>>> But we should never go backwards and TCP dropping from 750 Mbps to >>>> ~550 >>>> Mbps is a huge drop, so this is not ok. We have to do something to >>>> fix >>>> this, be it reverting the wake_tx_queue support, somehow disabling >>>> it by >>>> default or something. >>> >>> I would agree with Kalle here. This looks like very serious >>> regression. >>> But I'm afraid I can only help with testing here. >> >> Can you give the following patch a try, please? I didn't get to >> reproduce your problem on a real AP135/AP152 board and instead tried >> to simulate a slow uni-proc system via KVM and cooling_device in >> sysfs. The patch does improve things in this synthetic setup for me. >> >> http://lists.infradead.org/pipermail/ath10k/2016-May/007526.html >> > > Unfortunately doesn't seem to make any difference at all (really, if > there is, it's less than 10Mbps). > Please see this thread also: > https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041445.html > That is with your and Eric's patch applied. > Roman, Can you please try without registering wake_tx_queue callback? software queuing is needed for devices that supports peer-flow-control. .config = ath10k_config, -Rajkumar diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 6829a08638b2..5df904169ded 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -7313,7 +7313,6 @@ ath10k_mac_op_switch_vif_chanctx(struct ieee80211_hw *hw, static const struct ieee80211_ops ath10k_ops = { .tx = ath10k_mac_op_tx, - .wake_tx_queue = ath10k_mac_op_wake_tx_queue, .start = ath10k_start, .stop = ath10k_stop,