From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.toke.dk ([52.28.52.200]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gwrCq-0004iv-0G for ath10k@lists.infradead.org; Thu, 21 Feb 2019 16:28:18 +0000 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Subject: Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips In-Reply-To: <871s41nmvx.fsf@kamboji.qca.qualcomm.com> References: <1533724802-30944-1-git-send-email-wgong@codeaurora.org> <1533724802-30944-3-git-send-email-wgong@codeaurora.org> <87sh3pdtpg.fsf@toke.dk> <87mutue4y8.fsf@toke.dk> <1535967508.3437.31.camel@sipsolutions.net> <87in3m25uu.fsf@toke.dk> <1535975240.3437.61.camel@sipsolutions.net> <878t4i1z74.fsf@toke.dk> <871sa7ylmi.fsf@toke.dk> <87r2c1i1vj.fsf@toke.dk> <871s41nmvx.fsf@kamboji.qca.qualcomm.com> Date: Thu, 21 Feb 2019 17:28:13 +0100 Message-ID: <87h8cxhzs2.fsf@toke.dk> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Kalle Valo Cc: Kan Yan , wgong@qti.qualcomm.com, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, Grant Grundler , wgong@codeaurora.org, Johannes Berg S2FsbGUgVmFsbyA8a3ZhbG9AY29kZWF1cm9yYS5vcmc+IHdyaXRlczoKCj4gVG9rZSBIw7hpbGFu ZC1Kw7hyZ2Vuc2VuIDx0b2tlQHRva2UuZGs+IHdyaXRlczoKPgo+PiBHcmFudCBHcnVuZGxlciA8 Z3J1bmRsZXJAZ29vZ2xlLmNvbT4gd3JpdGVzOgo+Pgo+Pj4gT24gVGh1LCBTZXAgNiwgMjAxOCBh dCAzOjE4IEFNIFRva2UgSMO4aWxhbmQtSsO4cmdlbnNlbiA8dG9rZUB0b2tlLmRrPiB3cm90ZToK Pj4+Pgo+Pj4+IEdyYW50IEdydW5kbGVyIDxncnVuZGxlckBnb29nbGUuY29tPiB3cml0ZXM6Cj4+ Pj4KPj4+PiA+PiBBbmQsIHdlbGwsIEdyYW50J3MgZGF0YSBpcyBmcm9tIGEgc2luZ2xlIHRlc3Qg aW4gYSBub2lzeQo+Pj4+ID4+IGVudmlyb25tZW50IHdoZXJlIHRoZSB0aW1lIHNlcmllcyBncmFw aCBzaG93cyB0aGF0IHRocm91Z2hwdXQgaXMgYWxsIG92ZXIKPj4+PiA+PiB0aGUgcGxhY2UgZm9y IHRoZSBkdXJhdGlvbiBvZiB0aGUgdGVzdDsgc28gaXQncyBoYXJkIHRvIGRyYXcgc29saWQKPj4+ PiA+PiBjb25jbHVzaW9ucyBmcm9tIChmb3IgaW5zdGFuY2UsIGZvciB0aGUgNS1zdHJlYW0gdGVz dCwgdGhlIGF2ZXJhZ2UKPj4+PiA+PiB0aHJvdWdocHV0IGZvciA2IGlzIDMzMSBhbmQgMzc5IE1i cHMgZm9yIHRoZSB0d28gcmVwZXRpdGlvbnMsIGFuZCBmb3IgNwo+Pj4+ID4+IGl0J3MgMzI2IGFu ZCAzNzEgTWJwcykgLiBVbmZvcnR1bmF0ZWx5IEkgZG9uJ3QgaGF2ZSB0aGUgc2FtZSBoYXJkd2Fy ZQo+Pj4+ID4+IHVzZWQgaW4gdGhpcyB0ZXN0LCBzbyBJIGNhbid0IGdvIHZlcmlmeSBpdCBteXNl bGY7IHNvIHRoZSBvbmx5IHRoaW5nIEkKPj4+PiA+PiBjYW4gZG8gaXMgZ3J1bWJsZSBhYm91dCBp dCBoZXJlLi4uIDopCj4+Pj4gPgo+Pj4+ID4gSXQncyBhIGZhaXIgY29tcGxhaW50IGFuZCBJIGFn cmVlIHdpdGggaXQuIE15IGNvdW50ZXIgYXJndW1lbnQgaXMgdGhlCj4+Pj4gPiBvcHBvc2l0ZSBp cyB0cnVlIHRvbzogbW9zdCBpZGVhbCBiZW5jaG1hcmtzIGRvbid0IG1lYXN1cmUgd2hhdCBtb3N0 Cj4+Pj4gPiB1c2VycyBzZWUuIFdoaWxlIHRoZSBkYXRhIHdnb25nIHByb3ZpZGVkIGFyZSB3YXkg bW9yZSBub2lzeSB0aGFuIEkKPj4+PiA+IGxpa2UsIG15IG92ZXJhbGwgImNvbmZpZGVuY2UiIGlu IHRoZSAiY29uY2x1c2lvbiIgSSBvZmZlcmVkIGlzIHN0aWxsCj4+Pj4gPiBwb3NpdGl2ZS4KPj4+ Pgo+Pj4+IFJpZ2h0LiBJIGd1ZXNzIEkgd291bGQganVzdCBwcmVmZXIgYSBzbGlnaHRseSBtb3Jl IGNvbXByZWhlbnNpdmUKPj4+PiBldmFsdWF0aW9uIHRvIGJhc2UgYSA0eCBpbmNyZWFzZSBpbiBi dWZmZXIgc2l6ZSBvbi4uLgo+Pj4KPj4+IEthbGxlLCBpcyB0aGlzIHdoeSB5b3UgZGlkbid0IGFj Y2VwdCB0aGlzIHBhdGNoPyBPdGhlciByZWFzb25zPwo+Pj4KPj4+IFRva2UsIHdoYXQgZWxzZSB3 b3VsZCB5b3UgbGlrZSB0byBzZWUgZXZhbHVhdGVkPwo+Pj4KPj4+IEkgZ2VuZXJhbGx5IHdhbnQg dG8gc2VlIHRocmVlIHRoaW5ncyBtZWFzdXJlZCB3aGVuICJiZW5jaG1hcmtpbmciCj4+PiB0ZWNo bm9sb2dpZXM6IHRocm91Z2hwdXQsIGxhdGVuY3ksIGNwdSB1dGlsaXphdGlvbgo+Pj4gV2UndmUg Y292ZXJlZCB0aG9zZSB0aHJlZSBJIHRoaW5rICJyZWFzb25hYmx5Ii4KPj4KPj4gSG1tLCBnb2lu ZyBiYWNrIGFuZCBsb29raW5nIGF0IHRoaXMgKEknZCBjb21wbGV0ZWx5IGZvcmdvdHRlbiBhYm91 dCB0aGlzCj4+IHBhdGNoKSwgSSB0aGluayBJIGhhZCB0d28gbWFpbiBjb25jZXJuczoKPj4KPj4g MS4gV2hhdCBoYXBwZW5zIGluIGEgZGVncmFkZWQgc2lnbmFsIHNpdHVhdGlvbiwgd2hlcmUgdGhl IHRocm91Z2hwdXQgaXMKPj4gICAgbGltaXRlZCBieSB0aGUgc2lnbmFsIGNvbmRpdGlvbnMsIG9y IGJ5IGNvbnRlbnRpb24gd2l0aCBvdGhlciBkZXZpY2VzLgo+PiAgICBCb3RoIG9mIHRoZXNlIGhh cHBlbiByZWd1bGFybHksIGFuZCBJIHdvcnJ5IHRoYXQgbGF0ZW5jeSB3aWxsIGJlCj4+ICAgIGJh ZGx5IGFmZmVjdGVkIHVuZGVyIHRob3NlIGNvbmRpdGlvbnMuCj4+Cj4+IDIuIFdoYXQgaGFwcGVu cyB3aXRoIG9sZCBoYXJkd2FyZSB0aGF0IGhhcyB3b3JzZSBidWZmZXIgbWFuYWdlbWVudCBpbgo+ PiAgICB0aGUgZHJpdmVyLT5maXJtd2FyZSBwYXRoIChlc3BlY2lhbGx5IGRyaXZlcnMgd2l0aG91 dCBwdXNoL3B1bGwgbW9kZQo+PiAgICBzdXBwb3J0KT8gRm9yIHRoZXNlLCB0aGUgbG93ZXItbGV2 ZWwgcXVldWVpbmcgc3RydWN0dXJlIGlzIGxlc3MKPj4gICAgZWZmZWN0aXZlIGF0IGNvbnRyb2xs aW5nIHF1ZXVlaW5nIGxhdGVuY3kuCj4KPiBEbyBub3RlIHRoYXQgdGhpcyBwYXRjaCBjaGFuZ2Vz IGJlaGF2aW91ciBfb25seV8gZm9yIFFDQTYxNzQgYW5kIFFDQTkzNzcKPiBQQ0kgZGV2aWNlcywg d2hpY2ggSUlSQyBkbyBub3QgZXZlbiBzdXBwb3J0IHB1c2gvcHVsbCBtb2RlLiBBbGwgdGhlCj4g cmVzdCwgaW5jbHVkaW5nIFFDQTk4OFggYW5kIFFDQTk5ODQgYXJlIHVuYWZmZWN0ZWQuCgpBaCwg cmlnaHQ7IEkgZGlkIG5vdCBnbyBhbGwgdGhlIHdheSBiYWNrIGFuZCBsb29rIGF0IHRoZSBhY3R1 YWwgcGF0Y2gsCnNvIG1pc3NlZCB0aGF0IDopCgpCdXQgaW4gdGhhdCBjYXNlLCB3aHkgYXJlIHRo ZSBsYXRlbmN5IHJlc3VsdHMgdGhhdCBsb3c/IFdlcmUgdGhlc2UgdGVzdHMKZG9uZSB3aXRoIHRo ZSBDaHJvbWVPUyBxdWV1ZSBsaW1pdCBwYXRjaGVzPwoKLVRva2UKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmF0aDEwayBtYWlsaW5nIGxpc3QKYXRoMTBr QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9s aXN0aW5mby9hdGgxMGsK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14ABCC43381 for ; Thu, 21 Feb 2019 16:28:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D271020818 for ; Thu, 21 Feb 2019 16:28:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=toke.dk header.i=@toke.dk header.b="U+USLZ49" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726443AbfBUQ2Q (ORCPT ); Thu, 21 Feb 2019 11:28:16 -0500 Received: from mail.toke.dk ([52.28.52.200]:33599 "EHLO mail.toke.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726074AbfBUQ2P (ORCPT ); Thu, 21 Feb 2019 11:28:15 -0500 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1550766493; bh=iDVF5lk1zkMLaLHGvFxpP6V8/4NmnIFHAlfcQBjNGD8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=U+USLZ49I1EclHBRee+H5I3iQoVNyFPIATiPZDJYhL+zlUfqeiM7jdVNEmMDx01DW OTCO68DsTrY6oC2IyN9rQ57UaEJzZJXo5FUs8Sxdn5uMGHYyFJ68ED4TXafA2fsG0s 0fnIfeF97q040Y7r5ZSHQLNBiyuNblCrMHldkpsB0VvKUL7Vim9swtCvVrxZCCNg40 eF4pix3JpTQunrlVNHNyjo5a5D2ZXxazS25aVgkegJ8Yoq3Y7OCck1obwNTrw/gF08 thGJcuuY24uPmFGw8BfQPe8IrOn7Lge6G4StFE5PxacXLMERQJfCi/GUg2hvMy6rES PyFT8DiLj/UHw== To: Kalle Valo Cc: Grant Grundler , Kan Yan , linux-wireless@vger.kernel.org, Johannes Berg , wgong@qti.qualcomm.com, ath10k@lists.infradead.org, wgong@codeaurora.org Subject: Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips In-Reply-To: <871s41nmvx.fsf@kamboji.qca.qualcomm.com> References: <1533724802-30944-1-git-send-email-wgong@codeaurora.org> <1533724802-30944-3-git-send-email-wgong@codeaurora.org> <87sh3pdtpg.fsf@toke.dk> <87mutue4y8.fsf@toke.dk> <1535967508.3437.31.camel@sipsolutions.net> <87in3m25uu.fsf@toke.dk> <1535975240.3437.61.camel@sipsolutions.net> <878t4i1z74.fsf@toke.dk> <871sa7ylmi.fsf@toke.dk> <87r2c1i1vj.fsf@toke.dk> <871s41nmvx.fsf@kamboji.qca.qualcomm.com> Date: Thu, 21 Feb 2019 17:28:13 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87h8cxhzs2.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Kalle Valo writes: > Toke H=C3=B8iland-J=C3=B8rgensen writes: > >> Grant Grundler writes: >> >>> On Thu, Sep 6, 2018 at 3:18 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>>> >>>> Grant Grundler writes: >>>> >>>> >> And, well, Grant's data is from a single test in a noisy >>>> >> environment where the time series graph shows that throughput is al= l over >>>> >> the place for the duration of the test; so it's hard to draw solid >>>> >> conclusions from (for instance, for the 5-stream test, the average >>>> >> throughput for 6 is 331 and 379 Mbps for the two repetitions, and f= or 7 >>>> >> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardwa= re >>>> >> used in this test, so I can't go verify it myself; so the only thin= g I >>>> >> can do is grumble about it here... :) >>>> > >>>> > It's a fair complaint and I agree with it. My counter argument is the >>>> > opposite is true too: most ideal benchmarks don't measure what most >>>> > users see. While the data wgong provided are way more noisy than I >>>> > like, my overall "confidence" in the "conclusion" I offered is still >>>> > positive. >>>> >>>> Right. I guess I would just prefer a slightly more comprehensive >>>> evaluation to base a 4x increase in buffer size on... >>> >>> Kalle, is this why you didn't accept this patch? Other reasons? >>> >>> Toke, what else would you like to see evaluated? >>> >>> I generally want to see three things measured when "benchmarking" >>> technologies: throughput, latency, cpu utilization >>> We've covered those three I think "reasonably". >> >> Hmm, going back and looking at this (I'd completely forgotten about this >> patch), I think I had two main concerns: >> >> 1. What happens in a degraded signal situation, where the throughput is >> limited by the signal conditions, or by contention with other devices. >> Both of these happen regularly, and I worry that latency will be >> badly affected under those conditions. >> >> 2. What happens with old hardware that has worse buffer management in >> the driver->firmware path (especially drivers without push/pull mode >> support)? For these, the lower-level queueing structure is less >> effective at controlling queueing latency. > > Do note that this patch changes behaviour _only_ for QCA6174 and QCA9377 > PCI devices, which IIRC do not even support push/pull mode. All the > rest, including QCA988X and QCA9984 are unaffected. Ah, right; I did not go all the way back and look at the actual patch, so missed that :) But in that case, why are the latency results that low? Were these tests done with the ChromeOS queue limit patches? -Toke