From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.taht.net ([2a01:7e00::f03c:91ff:feae:7028]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gOt04-0001DU-DG for ath10k@lists.infradead.org; Mon, 19 Nov 2018 23:30:42 +0000 From: Dave Taht Subject: Re: [Make-wifi-fast] [PATCH v3 3/6] mac80211: Add airtime accounting and scheduling to TXQs References: <1542063113-22438-1-git-send-email-rmanohar@codeaurora.org> <1542063113-22438-4-git-send-email-rmanohar@codeaurora.org> <871s7nv9pl.fsf@toke.dk> <8e7847ff-4c88-10ae-2223-2fc7321641d9@nbd.name> <87sh02tfsp.fsf@toke.dk> <878t1p2bqz.fsf@taht.net> <87muq4sn50.fsf@toke.dk> Date: Mon, 19 Nov 2018 15:30:12 -0800 In-Reply-To: <87muq4sn50.fsf@toke.dk> ("Toke \=\?utf-8\?Q\?H\=C3\=B8iland-J\?\= \=\?utf-8\?Q\?\=C3\=B8rgensen\=22's\?\= message of "Mon, 19 Nov 2018 14:44:43 -0800") Message-ID: <87efbgejcr.fsf@taht.net> 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: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, Rajkumar Manoharan , Felix Fietkau VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2VuIDx0b2tlQHRva2UuZGs+IHdyaXRlczoKCj4gRGF2ZSBU YWh0IDxkYXZlQHRhaHQubmV0PiB3cml0ZXM6Cj4KPj4gVG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu IDx0b2tlQHRva2UuZGs+IHdyaXRlczoKPj4KPj4+IEZlbGl4IEZpZXRrYXUgPG5iZEBuYmQubmFt ZT4gd3JpdGVzOgo+Pj4KPj4+PiBPbiAyMDE4LTExLTE0IDE4OjQwLCBUb2tlIEjDuGlsYW5kLUrD uHJnZW5zZW4gd3JvdGU6Cj4+Pj4+PiBUaGlzIHBhcnQgZG9lc24ndCByZWFsbHkgbWFrZSBtdWNo IHNlbnNlIHRvIG1lLCBidXQgbWF5YmUgSSdtCj4+Pj4+PiBtaXN1bmRlcnN0YW5kaW5nIGhvdyB0 aGUgY29kZSB3b3Jrcy4KPj4+Pj4+IExldCdzIGFzc3VtZSB3ZSBoYXZlIGEgZHJpdmVyIGxpa2Ug YXRoOWsgb3IgbXQ3Niwgd2hpY2ggdHJpZXMgdG8ga2VlcCBhCj4+Pj4+PiBudW1iZXIgb2YgYWdn cmVnYXRlcyBpbiB0aGUgaGFyZHdhcmUgcXVldWUsIGFuZCB0aGUgaGFyZHdhcmUgcXVldWUgaXMK Pj4+Pj4+IGN1cnJlbnRseSBlbXB0eS4KPj4+Pj4+IElmIHRoZSBjdXJyZW50IHR4cSBlbnRyeSBp cyBrZXB0IGF0IHRoZSBoZWFkIG9mIHRoZSBzY2hlZHVsZSBsaXN0LAo+Pj4+Pj4gd291bGRuJ3Qg dGhlIGNvZGUganVzdCBwdWxsIGZyb20gdGhhdCBvbmUgb3ZlciBhbmQgb3ZlciBhZ2FpbiwgdW50 aWwKPj4+Pj4+IGVub3VnaCBwYWNrZXRzIGFyZSB0cmFuc21pdHRlZCBieSB0aGUgaGFyZHdhcmUg YW5kIHRoZWlyIHR4IHN0YXR1cwo+Pj4+Pj4gcHJvY2Vzc2VkPwo+Pj4+Pj4gSXQgc2VlbXMgdG8g bWUgdGhhdCB3aGlsZSBmYWlybmVzcyBpcyBzdGlsbCBwcmVzZXJ2ZWQgaW4gdGhlIGxvbmcgcnVu LAo+Pj4+Pj4gdGhpcyBjb3VsZCBsZWFkIHRvIHJhdGhlciBidXJzdHkgc2NoZWR1bGluZywgd2hp Y2ggbWF5IG5vdCBiZQo+Pj4+Pj4gcGFydGljdWxhcmx5IGxhdGVuY3kgZnJpZW5kbHkuCj4+Pj4+ IAo+Pj4+PiBZZXMsIGl0J2xsIGJlIGEgYml0IG1vcmUgYnVyc3R5IHdoZW4gdGhlIGhhcmR3YXJl IHF1ZXVlIGlzIGNvbXBsZXRlbHkKPj4+Pj4gZW1wdHkuIEhvd2V2ZXIsIHdoZW4gYSBUWCBjb21w bGV0aW9uIGNvbWVzIGJhY2ssIHRoYXQgd2lsbCBhZGp1c3QgdGhlCj4+Pj4+IGRlZmljaXQgb2Yg dGhhdCBzdGEgYW5kIGNhdXNlIGl0IHRvIGJlIHJvdGF0ZWQgb24gdGhlIG5leHQgZGVxdWV1ZS4g VGhpcwo+Pj4+PiBvYnZpb3VzbHkgcmVsaWVzIG9uIHRoZSBmYWN0IHRoYXQgdGhlIGxvd2VyLWxl dmVsIGhhcmR3YXJlIHF1ZXVlIGlzCj4+Pj4+IHN1ZmZpY2llbnRseSBzaGFsbG93IHRvIG5vdCBh ZGQgYSBsb3Qgb2YgbGF0ZW5jeS4gQnV0IHdlIHdhbnQgdGhhdCB0byBiZQo+Pj4+PiB0aGUgY2Fz ZSBhbnl3YXkuIEluIHByYWN0aWNlLCBpdCB3b3JrcyBxdWl0ZSB3ZWxsIGZvciBhdGg5aywgYnV0 IG5vdCBzbwo+Pj4+PiB3ZWxsIGZvciBhdGgxMGsgYmVjYXVzZSBpdCBoYXMgYSBsYXJnZSBidWZm ZXIgaW4gZmlybXdhcmUuCj4+Pj4+IAo+Pj4+PiBJZiB3ZSByZXF1ZXVlIHRoZSBUWFEgYXQgdGhl IGVuZCBvZiB0aGUgbGlzdCwgYSBzdGF0aW9uIHRoYXQgaXMgdGFraW5nCj4+Pj4+IHVwIHRvbyBt dWNoIGFpcnRpbWUgd2lsbCBmYWlsIHRvIGJlIHRocm90dGxlZCBwcm9wZXJseSwgc28gdGhlCj4+ Pj4+IHF1ZXVlLWF0LWhlYWQgaXMga2luZGEgbmVlZGVkIHRvIGVuc3VyZSBmYWlybmVzcy4uLgo+ Pj4+IFRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9uLCB0aGF0IG1ha2VzIHNlbnNlIHRvIG1lLiBJ IGhhdmUgYW4gaWRlYSBvbgo+Pj4+IGhvdyB0byBtaXRpZ2F0ZSB0aGUgYnVyc3RpbmVzcyB3aXRo aW4gdGhlIGRyaXZlci4gSSdsbCB3cml0ZSBpdCBkb3duIGluCj4+Pj4gcHNldWRvY29kZSwgcGxl YXNlIGxldCBtZSBrbm93IGlmIHlvdSB0aGluayB0aGF0J2xsIHdvcmsuCj4+Pgo+Pj4gSSBkb24n dCB0aGluayBpdCB3aWxsLCB1bmZvcnR1bmF0ZWx5LiBGb3IgZXhhbXBsZSwgY29uc2lkZXIgdGhl IGNhc2UKPj4+IHdoZXJlIHRoZXJlIGFyZSB0d28gc3RhdGlvbnMgcXVldWVkOyBvbmUgd2l0aCBh IGxhcmdlIG5lZ2F0aXZlIGRlZmljaXQKPj4+IChzYXksIC0xMG1zKSwgYW5kIG9uZSB3aXRoIGEg cG9zaXRpdmUgZGVmaWNpdC4KPj4KPj4gUGVyaGFwcyBhIGZsYWcgZm9yIG9uZSB3YXkgb3IgdGhl IG90aGVyPwo+Pgo+PiBpZihkcml2ZXItPmhhc19hYnN1cmRfaGFyZHdhcmVfcXVldWVfZGVwdGgp IGRvaXR0aGlzd2F5KCk7IGVsc2UKPj4gZG9pdGFiZXR0ZXJ3YXkoKTsKPgo+IFdlbGwsIHRoZXJl J3MgZ29pbmcgdG8gYmUgYSBCUUwtbGlrZSBxdWV1ZSBsaW1pdCAoYnV0IGZvciBhaXJ0aW1lKSBv bgo+IHRvcCwgd2hpY2ggZHJpdmVycyBjYW4gb3B0LWluIHRvIGlmIHRoZSBoYXJkd2FyZSBoYXMg dG9vIG11Y2ggcXVldWVpbmcuCj4KPj4+IEluIHRoaXMgY2FzZSwgd2UgcmVhbGx5IG5lZWQgdG8g dGhyb3R0bGUgdGhlIHN0YXRpb24gd2l0aCBhIG5lZ2F0aXZlCj4+PiBkZWZpY2l0LiBCdXQgaWYg dGhlIGRyaXZlciBsb29wcyBhbmQgY2FjaGVzIHR4cXMsIHdlJ2xsIGdldCBzb21ldGhpbmcKPj4+ IGxpa2UgdGhlIGZvbGxvd2luZzoKPj4+Cj4+PiAtIEZpcnN0IGRyaXZlciBsb29wIGl0ZXJhdGlv bjogcmV0dXJucyBUWFEgd2l0aCBwb3NpdGl2ZSBkZWZpY2l0Lgo+Pj4gLSBTZWNvbmQgZHJpdmVy IGxvb3AgaXRlcmF0aW9uOiBPbmx5IHRoZSBuZWdhdGl2ZS1kZWZpY2l0IFRYUSBpcyBpbiB0aGUK Pj4+ICAgbWFjODAyMTEgbGlzdCwgc28gaXQgd2lsbCBsb29wIHVudGlsIHRoYXQgVFhRJ3MgZGVm aWNpdCB0dXJucyBwb3NpdGl2ZQo+Pj4gICBhbmQgcmV0dXJuIGl0Lgo+Pj4KPj4+IEJlY2F1c2Ug b2YgdGhpcywgdGhlIG5lZ2F0aXZlLWRlZmljaXQgc3RhdGlvbiB3b24ndCBiZSB0aHJvdHRsZWQs IGFuZCB3ZQo+Pj4gd29uJ3QgZ2V0IGZhaXJuZXNzLgo+Pj4KPj4+IEhvdyBtYW55IGZyYW1lcyB3 aWxsIG10NzYgcXVldWUgdXAgYmVsb3cgdGhlIGRyaXZlciBwb2ludD8gSS5lLiwgaG93Cj4+PiBt dWNoIGJ1cnN0aW5lc3MgYXJlIHlvdSBleHBlY3RpbmcgdGhpcyB3aWxsIGludHJvZHVjZSBvbiB0 aGF0IGRyaXZlcj8KPj4+Cj4+PiBUYWtpbmcgYSBzdGVwIGJhY2ssIGl0J3MgY2xlYXIgdGhhdCBp dCB3b3VsZCBiZSBnb29kIHRvIGJlIGFibGUgdG8KPj4+IGRlcXVldWUgcGFja2V0cyB0byBtdWx0 aXBsZSBTVEFzIGF0IG9uY2UgKHdlIG5lZWQgdGhhdCBmb3IgTVUtTUlNTyBvbgo+Pj4gYXRoMTBr IGFzIHdlbGwpLiBIb3dldmVyLCBJIGRvbid0IHRoaW5rIHdlIGNhbiBkbyB0aGF0IHdpdGggdGhl Cj4+PiByb3VuZC1yb2JpbiBmYWlybmVzcyBzY2hlZHVsZXI7IHNvIHdlIGFyZSBnb2luZyB0byBu ZWVkIGEgZGlmZmVyZW50Cj4+PiBhbGdvcml0aG0uIEkgKnRoaW5rKiBpdCBtYXkgYmUgcG9zc2li bGUgdG8gZG8gdGhpcyB3aXRoIGEgdmlydHVhbC10aW1lCj4+PiBzY2hlZHVsZXIsIGJ1dCBJIGhh dmVuJ3Qgc2F0IGRvd24gYW5kIHdvcmtlZCBvdXQgdGhlIGRldGFpbHMgeWV0Li4uCj4+Cj4+IFRo ZSBhbnN3ZXIgdG8gd2hpY2ggZGlkIG5vdCBmaXQgb24gdGhlIG1hcmdpbnMgb2YgeW91ciB0aGVz aXMuIDopCj4+Cj4+IEkgdG9vIGhhdmUgYmVlbiB0cnlpbmcgdG8gY29tZSB1cCB3aXRoIGEgYmV0 dGVyIG1lYW5zIG9mIGdhbmcKPj4gc2NoZWR1bGluZy4uLiBmb3IgYWJvdXQgMiB5ZWFycyBub3cu IEluIHRlcm1zIG9mIGJpdG1hcHMgaXQgbG9va3MgYSBiaXQKPj4gbGlrZSBRRlEsIGJ1dCBob25l c3RseS4uLgo+Cj4gSXQncyBub3QgdGhlIGdhbmcgc2NoZWR1bGluZyB3ZSBuZWVkLCBkZWNpZGlu ZyB3aGljaCBkZXZpY2VzIHRvIHNlbmQgdG8KPiBhdCBvbmNlIGlzIGdlbmVyYWxseSBkb25lIGlu IGZpcm13YXJlIGFueXdheS4KCkkgaGF2ZSBhIGxvbmcgaGVsZCBkcmVhbSB0aGF0IG9uZSBkYXkg c29tZSBmaXJtd2FyZSB3aWxsIGJlIGFibGUgdG8gc2VuZAphbiBpbnRlcnJ1cHQgYW5kIHNvbWUg aW5mb3JtYXRpb24gYWxvbmcuLi4KCiJIaSwgSSdsbCBiZSBkb25lIHRyYW5zbWl0dGluZy9yZWNl aXZpbmcgaW4gYWJvdXQgMW1zLCBoZXJlJ3Mgd2hvIEkKdGhpbmsgSSBjYW4gdGFsayB0byBuZXh0 LCBhbmQgaGVyZSdzIHdobyBlbHNlIEkgbWF5YmUgY291bGQgZ2FuZyBzY2hlZHVsZSIuCgpUaGF0 IHdvdWxkIGxldCB1cyBnZXQgYXdheSBmcm9tIDVtcyB3YXN0ZWQgaW4gdGhlICJyZWFkeSB0byBn byIgcG9ydGlvbgpvZiB0aGUgYWxnbywgYW5kIHNoYXJlIHRoZSBoaWdoZXN0IGxpa2VseWhvb2Qg Imdyb3VwcyIgd2l0aCB0aGUgaGlnaGVyCmxheWVyLgoKPiBXZSBqdXN0IG5lZWQgdG8gYmUgYWJs ZSB0bwo+IGRlcXVldWUgcGFja2V0cyBmb3IgbW9yZSB0aGFuIG9uZSBzdGF0aW9uIHdoZW4gcG9z c2libGUuCgpBbmQgYSBodWdlIGZhbnRhc3kgaXMgaW4gc29tZSBmdXR1cmUgODAyLjExWlpaIHN0 YW5kYXJkIHRoZSBvbi1ib2FyZCBmaXJtd2FyZSBhbmQKdGhlIGxpbnV4IGRyaXZlcnMgY2FuIGJl IGNvLWRlc2lnbmVkLCBldmVuLCBkYXJlIEkgc2F5LCBvcGVuIHNvdXJjZWQsIHRvCmJldHRlciBl dm9sdmUgdG8gbWVldCByZWFsIHdvcmxkIHJlcXVpcmVtZW50cy4KCm1ib3gncyBwZXIgc3RhdGlv biB3b3VsZCBiZSBuaWNlLCB3aXRoIHNjYXR0ZXIvZ2F0aGVyIEkvTy4uLiBJCmNhbiB0aGluayBv ZiBhIHppbGxpb24gdGhpbmdzIEknZCB3YW50IHRoZSBmaXJtd2FyZSB0byBoYW5kbGUgKG90aGVy CnRoYW4gYnVmZmVyaW5nKQoKPiBJIGRvbid0IHRoaW5rCj4gd2UgbmVlZCB0aGUgZmFuY3kgYml0 bWFwIHN0dWZmIGZyb20gUUZRIHNpbmNlIHdlIGRvbid0IGhhdmUgdGhhdCBtYW55Cj4gc3RhdGlv bnMgdG8gc2NoZWR1bGUgYXQgb25jZTsgc28gd2UgY2FuIHByb2JhYmx5IGxpdmUgd2l0aCBPKGxv ZyhuKSkgaW4KPiB0aGUgbnVtYmVyIG9mIGFjdGl2ZSBzdGF0aW9ucy4KCkJlc3Qgb2YgdHdvIG9y IHRocmVlICJncm91cHMiLCBwZXIgYWJvdmUsIGZyb20gdGhlIGZpcm13YXJlLgoKPj4gSXMgdGhl cmUgZ29pbmcgdG8gYmUgc29tZSBwb2ludCB3aGVyZSB3aGF0ZXZlciB3ZSBoYXZlIGhlcmUgaXMK Pj4gc2lnbmlmaWNhbnRseSBiZXR0ZXIgdGhhbiB3aGF0IHdlIGhhZD8gT3Igbm90IHNpZ25pZmlj YW50bHkgd29yc2U/IE9yCj4+IGhhbmR3YXZ5IGVub3VnaCB0byBmaXggdGhlIHJlc3Qgb25jZSBl bmxpZ2h0ZW5tZW50IGFycml2ZXM/Cj4+Cj4+IFRoZSBwZXJmZWN0IGlzIHRoZSBlbmVteSBvZiB0 aGUgZ29vZC4KPgo+IFdlbGwsIHdoYXQgd2UgaGF2ZSBub3cgd29ya3MgZm9yIGF0aDlrLCB3b3Jr cyByZWFzb25hYmx5IHdlbGwgZm9yIGF0aDEwawo+IGluIHB1bGwgbW9kZSwgbm90IHNvIHdlbGwg Zm9yIGF0aDEwayBpbiBwdXNoIG1vZGUsIGFuZCB0aGVuIHRoZXJlJ3MKPiBGZWxpeCcgY29tbWVu dHMgaW4gdGhpcyB0aHJlYWQuLi4KClNvIGhvdyBhYm91dCwgYW4gYXRoMTBrIGluIGEgZnJpZ2dp biAiY28tb3BlcmF0aXZlIiBtb2RlPyAKCldoYXQgYXJlIHRoZSBwZXJmb3JtYW5jZSBkaWZmZXJl bmNlcyBpbiBhdGgxMGsgaW4gcHVzaCBtb2RlPyBXaHkgZG8gd2UKY2FyZSBpZiB0aGlzIG1vZGUg d29ya3MgYXQgYWxsPyAKClBlcmZlY3QsIHZlcnNlcyAiZ29vZCIuCgo+PiBJJ2QgcmF0aGVyIGxp a2UgdGhlIGludGVsIGZvbGsgdG8gYmUgd2VpZ2hpbmcgaW4gb24gdGhpcyBzdHVmZiwgdG9vLAo+ PiB0cnlpbmcgdG8gZ2V0IGFuIEFQSSByaWdodCByZXF1aXJlcyB1c2UgY2FzZXMuCj4KPiBKb2hh bm5lcyBoYXMgYWxyZWFkeSByZXZpZXdlZCBhIHByZXZpb3VzIHZlcnNpb24sIGFuZCBJIGRvIGJl bGlldmUgaGUKPiBzYWlkIGhlJ2QgcmV2aWV3IGl0IGFnYWluIG9uY2Ugd2UgaGF2ZSBjb252ZXJn ZWQgb24gc29tZXRoaW5nIDopCgpXb3VsZCBpbnRlbCBjYXJlIGlmIG9ubHkgdGhlIHB1bGwgbW9k ZSB3b3JrZWQgd2VsbCBvbiB0aGVpciBoYXJkd2FyZT8gRG8KdGhleSBoYXZlIGEgcHVsbCBvciBw dXNoIG1vZGU/CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KYXRoMTBrIG1haWxpbmcgbGlzdAphdGgxMGtAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8v bGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F0aDEwawo= 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.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 D0922C43441 for ; Mon, 19 Nov 2018 23:30:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8EF5420851 for ; Mon, 19 Nov 2018 23:30:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8EF5420851 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=taht.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731677AbeKTJ4b convert rfc822-to-8bit (ORCPT ); Tue, 20 Nov 2018 04:56:31 -0500 Received: from mail.taht.net ([176.58.107.8]:56654 "EHLO mail.taht.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730692AbeKTJ4b (ORCPT ); Tue, 20 Nov 2018 04:56:31 -0500 Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 4D1A2228A5; Mon, 19 Nov 2018 23:30:24 +0000 (UTC) From: Dave Taht To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Cc: Felix Fietkau , Rajkumar Manoharan , linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, make-wifi-fast@lists.bufferbloat.net Subject: Re: [Make-wifi-fast] [PATCH v3 3/6] mac80211: Add airtime accounting and scheduling to TXQs References: <1542063113-22438-1-git-send-email-rmanohar@codeaurora.org> <1542063113-22438-4-git-send-email-rmanohar@codeaurora.org> <871s7nv9pl.fsf@toke.dk> <8e7847ff-4c88-10ae-2223-2fc7321641d9@nbd.name> <87sh02tfsp.fsf@toke.dk> <878t1p2bqz.fsf@taht.net> <87muq4sn50.fsf@toke.dk> Date: Mon, 19 Nov 2018 15:30:12 -0800 In-Reply-To: <87muq4sn50.fsf@toke.dk> ("Toke \=\?utf-8\?Q\?H\=C3\=B8iland-J\?\= \=\?utf-8\?Q\?\=C3\=B8rgensen\=22's\?\= message of "Mon, 19 Nov 2018 14:44:43 -0800") Message-ID: <87efbgejcr.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Toke Høiland-Jørgensen writes: > Dave Taht writes: > >> Toke Høiland-Jørgensen writes: >> >>> Felix Fietkau writes: >>> >>>> On 2018-11-14 18:40, Toke Høiland-Jørgensen wrote: >>>>>> This part doesn't really make much sense to me, but maybe I'm >>>>>> misunderstanding how the code works. >>>>>> Let's assume we have a driver like ath9k or mt76, which tries to keep a >>>>>> number of aggregates in the hardware queue, and the hardware queue is >>>>>> currently empty. >>>>>> If the current txq entry is kept at the head of the schedule list, >>>>>> wouldn't the code just pull from that one over and over again, until >>>>>> enough packets are transmitted by the hardware and their tx status >>>>>> processed? >>>>>> It seems to me that while fairness is still preserved in the long run, >>>>>> this could lead to rather bursty scheduling, which may not be >>>>>> particularly latency friendly. >>>>> >>>>> Yes, it'll be a bit more bursty when the hardware queue is completely >>>>> empty. However, when a TX completion comes back, that will adjust the >>>>> deficit of that sta and cause it to be rotated on the next dequeue. This >>>>> obviously relies on the fact that the lower-level hardware queue is >>>>> sufficiently shallow to not add a lot of latency. But we want that to be >>>>> the case anyway. In practice, it works quite well for ath9k, but not so >>>>> well for ath10k because it has a large buffer in firmware. >>>>> >>>>> If we requeue the TXQ at the end of the list, a station that is taking >>>>> up too much airtime will fail to be throttled properly, so the >>>>> queue-at-head is kinda needed to ensure fairness... >>>> Thanks for the explanation, that makes sense to me. I have an idea on >>>> how to mitigate the burstiness within the driver. I'll write it down in >>>> pseudocode, please let me know if you think that'll work. >>> >>> I don't think it will, unfortunately. For example, consider the case >>> where there are two stations queued; one with a large negative deficit >>> (say, -10ms), and one with a positive deficit. >> >> Perhaps a flag for one way or the other? >> >> if(driver->has_absurd_hardware_queue_depth) doitthisway(); else >> doitabetterway(); > > Well, there's going to be a BQL-like queue limit (but for airtime) on > top, which drivers can opt-in to if the hardware has too much queueing. > >>> In this case, we really need to throttle the station with a negative >>> deficit. But if the driver loops and caches txqs, we'll get something >>> like the following: >>> >>> - First driver loop iteration: returns TXQ with positive deficit. >>> - Second driver loop iteration: Only the negative-deficit TXQ is in the >>> mac80211 list, so it will loop until that TXQ's deficit turns positive >>> and return it. >>> >>> Because of this, the negative-deficit station won't be throttled, and we >>> won't get fairness. >>> >>> How many frames will mt76 queue up below the driver point? I.e., how >>> much burstiness are you expecting this will introduce on that driver? >>> >>> Taking a step back, it's clear that it would be good to be able to >>> dequeue packets to multiple STAs at once (we need that for MU-MIMO on >>> ath10k as well). However, I don't think we can do that with the >>> round-robin fairness scheduler; so we are going to need a different >>> algorithm. I *think* it may be possible to do this with a virtual-time >>> scheduler, but I haven't sat down and worked out the details yet... >> >> The answer to which did not fit on the margins of your thesis. :) >> >> I too have been trying to come up with a better means of gang >> scheduling... for about 2 years now. In terms of bitmaps it looks a bit >> like QFQ, but honestly... > > It's not the gang scheduling we need, deciding which devices to send to > at once is generally done in firmware anyway. I have a long held dream that one day some firmware will be able to send an interrupt and some information along... "Hi, I'll be done transmitting/receiving in about 1ms, here's who I think I can talk to next, and here's who else I maybe could gang schedule". That would let us get away from 5ms wasted in the "ready to go" portion of the algo, and share the highest likelyhood "groups" with the higher layer. > We just need to be able to > dequeue packets for more than one station when possible. And a huge fantasy is in some future 802.11ZZZ standard the on-board firmware and the linux drivers can be co-designed, even, dare I say, open sourced, to better evolve to meet real world requirements. mbox's per station would be nice, with scatter/gather I/O... I can think of a zillion things I'd want the firmware to handle (other than buffering) > I don't think > we need the fancy bitmap stuff from QFQ since we don't have that many > stations to schedule at once; so we can probably live with O(log(n)) in > the number of active stations. Best of two or three "groups", per above, from the firmware. >> Is there going to be some point where whatever we have here is >> significantly better than what we had? Or not significantly worse? Or >> handwavy enough to fix the rest once enlightenment arrives? >> >> The perfect is the enemy of the good. > > Well, what we have now works for ath9k, works reasonably well for ath10k > in pull mode, not so well for ath10k in push mode, and then there's > Felix' comments in this thread... So how about, an ath10k in a friggin "co-operative" mode? What are the performance differences in ath10k in push mode? Why do we care if this mode works at all? Perfect, verses "good". >> I'd rather like the intel folk to be weighing in on this stuff, too, >> trying to get an API right requires use cases. > > Johannes has already reviewed a previous version, and I do believe he > said he'd review it again once we have converged on something :) Would intel care if only the pull mode worked well on their hardware? Do they have a pull or push mode?