From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail.toke.dk ([2001:470:dc45:1000::1]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gOsI2-0007Uj-S3 for ath10k@lists.infradead.org; Mon, 19 Nov 2018 22:45:13 +0000 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Subject: Re: [Make-wifi-fast] [PATCH v3 3/6] mac80211: Add airtime accounting and scheduling to TXQs In-Reply-To: <878t1p2bqz.fsf@taht.net> 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> Date: Mon, 19 Nov 2018 14:44:43 -0800 Message-ID: <87muq4sn50.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: Dave Taht Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, Rajkumar Manoharan , Felix Fietkau RGF2ZSBUYWh0IDxkYXZlQHRhaHQubmV0PiB3cml0ZXM6Cgo+IFRva2UgSMO4aWxhbmQtSsO4cmdl bnNlbiA8dG9rZUB0b2tlLmRrPiB3cml0ZXM6Cj4KPj4gRmVsaXggRmlldGthdSA8bmJkQG5iZC5u YW1lPiB3cml0ZXM6Cj4+Cj4+PiBPbiAyMDE4LTExLTE0IDE4OjQwLCBUb2tlIEjDuGlsYW5kLUrD uHJnZW5zZW4gd3JvdGU6Cj4+Pj4+IFRoaXMgcGFydCBkb2Vzbid0IHJlYWxseSBtYWtlIG11Y2gg c2Vuc2UgdG8gbWUsIGJ1dCBtYXliZSBJJ20KPj4+Pj4gbWlzdW5kZXJzdGFuZGluZyBob3cgdGhl IGNvZGUgd29ya3MuCj4+Pj4+IExldCdzIGFzc3VtZSB3ZSBoYXZlIGEgZHJpdmVyIGxpa2UgYXRo OWsgb3IgbXQ3Niwgd2hpY2ggdHJpZXMgdG8ga2VlcCBhCj4+Pj4+IG51bWJlciBvZiBhZ2dyZWdh dGVzIGluIHRoZSBoYXJkd2FyZSBxdWV1ZSwgYW5kIHRoZSBoYXJkd2FyZSBxdWV1ZSBpcwo+Pj4+ PiBjdXJyZW50bHkgZW1wdHkuCj4+Pj4+IElmIHRoZSBjdXJyZW50IHR4cSBlbnRyeSBpcyBrZXB0 IGF0IHRoZSBoZWFkIG9mIHRoZSBzY2hlZHVsZSBsaXN0LAo+Pj4+PiB3b3VsZG4ndCB0aGUgY29k ZSBqdXN0IHB1bGwgZnJvbSB0aGF0IG9uZSBvdmVyIGFuZCBvdmVyIGFnYWluLCB1bnRpbAo+Pj4+ PiBlbm91Z2ggcGFja2V0cyBhcmUgdHJhbnNtaXR0ZWQgYnkgdGhlIGhhcmR3YXJlIGFuZCB0aGVp ciB0eCBzdGF0dXMKPj4+Pj4gcHJvY2Vzc2VkPwo+Pj4+PiBJdCBzZWVtcyB0byBtZSB0aGF0IHdo aWxlIGZhaXJuZXNzIGlzIHN0aWxsIHByZXNlcnZlZCBpbiB0aGUgbG9uZyBydW4sCj4+Pj4+IHRo aXMgY291bGQgbGVhZCB0byByYXRoZXIgYnVyc3R5IHNjaGVkdWxpbmcsIHdoaWNoIG1heSBub3Qg YmUKPj4+Pj4gcGFydGljdWxhcmx5IGxhdGVuY3kgZnJpZW5kbHkuCj4+Pj4gCj4+Pj4gWWVzLCBp dCdsbCBiZSBhIGJpdCBtb3JlIGJ1cnN0eSB3aGVuIHRoZSBoYXJkd2FyZSBxdWV1ZSBpcyBjb21w bGV0ZWx5Cj4+Pj4gZW1wdHkuIEhvd2V2ZXIsIHdoZW4gYSBUWCBjb21wbGV0aW9uIGNvbWVzIGJh Y2ssIHRoYXQgd2lsbCBhZGp1c3QgdGhlCj4+Pj4gZGVmaWNpdCBvZiB0aGF0IHN0YSBhbmQgY2F1 c2UgaXQgdG8gYmUgcm90YXRlZCBvbiB0aGUgbmV4dCBkZXF1ZXVlLiBUaGlzCj4+Pj4gb2J2aW91 c2x5IHJlbGllcyBvbiB0aGUgZmFjdCB0aGF0IHRoZSBsb3dlci1sZXZlbCBoYXJkd2FyZSBxdWV1 ZSBpcwo+Pj4+IHN1ZmZpY2llbnRseSBzaGFsbG93IHRvIG5vdCBhZGQgYSBsb3Qgb2YgbGF0ZW5j eS4gQnV0IHdlIHdhbnQgdGhhdCB0byBiZQo+Pj4+IHRoZSBjYXNlIGFueXdheS4gSW4gcHJhY3Rp Y2UsIGl0IHdvcmtzIHF1aXRlIHdlbGwgZm9yIGF0aDlrLCBidXQgbm90IHNvCj4+Pj4gd2VsbCBm b3IgYXRoMTBrIGJlY2F1c2UgaXQgaGFzIGEgbGFyZ2UgYnVmZmVyIGluIGZpcm13YXJlLgo+Pj4+ IAo+Pj4+IElmIHdlIHJlcXVldWUgdGhlIFRYUSBhdCB0aGUgZW5kIG9mIHRoZSBsaXN0LCBhIHN0 YXRpb24gdGhhdCBpcyB0YWtpbmcKPj4+PiB1cCB0b28gbXVjaCBhaXJ0aW1lIHdpbGwgZmFpbCB0 byBiZSB0aHJvdHRsZWQgcHJvcGVybHksIHNvIHRoZQo+Pj4+IHF1ZXVlLWF0LWhlYWQgaXMga2lu ZGEgbmVlZGVkIHRvIGVuc3VyZSBmYWlybmVzcy4uLgo+Pj4gVGhhbmtzIGZvciB0aGUgZXhwbGFu YXRpb24sIHRoYXQgbWFrZXMgc2Vuc2UgdG8gbWUuIEkgaGF2ZSBhbiBpZGVhIG9uCj4+PiBob3cg dG8gbWl0aWdhdGUgdGhlIGJ1cnN0aW5lc3Mgd2l0aGluIHRoZSBkcml2ZXIuIEknbGwgd3JpdGUg aXQgZG93biBpbgo+Pj4gcHNldWRvY29kZSwgcGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSB0aGlu ayB0aGF0J2xsIHdvcmsuCj4+Cj4+IEkgZG9uJ3QgdGhpbmsgaXQgd2lsbCwgdW5mb3J0dW5hdGVs eS4gRm9yIGV4YW1wbGUsIGNvbnNpZGVyIHRoZSBjYXNlCj4+IHdoZXJlIHRoZXJlIGFyZSB0d28g c3RhdGlvbnMgcXVldWVkOyBvbmUgd2l0aCBhIGxhcmdlIG5lZ2F0aXZlIGRlZmljaXQKPj4gKHNh eSwgLTEwbXMpLCBhbmQgb25lIHdpdGggYSBwb3NpdGl2ZSBkZWZpY2l0Lgo+Cj4gUGVyaGFwcyBh IGZsYWcgZm9yIG9uZSB3YXkgb3IgdGhlIG90aGVyPwo+Cj4gaWYoZHJpdmVyLT5oYXNfYWJzdXJk X2hhcmR3YXJlX3F1ZXVlX2RlcHRoKSBkb2l0dGhpc3dheSgpOyBlbHNlCj4gZG9pdGFiZXR0ZXJ3 YXkoKTsKCldlbGwsIHRoZXJlJ3MgZ29pbmcgdG8gYmUgYSBCUUwtbGlrZSBxdWV1ZSBsaW1pdCAo YnV0IGZvciBhaXJ0aW1lKSBvbgp0b3AsIHdoaWNoIGRyaXZlcnMgY2FuIG9wdC1pbiB0byBpZiB0 aGUgaGFyZHdhcmUgaGFzIHRvbyBtdWNoIHF1ZXVlaW5nLgoKPj4gSW4gdGhpcyBjYXNlLCB3ZSBy ZWFsbHkgbmVlZCB0byB0aHJvdHRsZSB0aGUgc3RhdGlvbiB3aXRoIGEgbmVnYXRpdmUKPj4gZGVm aWNpdC4gQnV0IGlmIHRoZSBkcml2ZXIgbG9vcHMgYW5kIGNhY2hlcyB0eHFzLCB3ZSdsbCBnZXQg c29tZXRoaW5nCj4+IGxpa2UgdGhlIGZvbGxvd2luZzoKPj4KPj4gLSBGaXJzdCBkcml2ZXIgbG9v cCBpdGVyYXRpb246IHJldHVybnMgVFhRIHdpdGggcG9zaXRpdmUgZGVmaWNpdC4KPj4gLSBTZWNv bmQgZHJpdmVyIGxvb3AgaXRlcmF0aW9uOiBPbmx5IHRoZSBuZWdhdGl2ZS1kZWZpY2l0IFRYUSBp cyBpbiB0aGUKPj4gICBtYWM4MDIxMSBsaXN0LCBzbyBpdCB3aWxsIGxvb3AgdW50aWwgdGhhdCBU WFEncyBkZWZpY2l0IHR1cm5zIHBvc2l0aXZlCj4+ICAgYW5kIHJldHVybiBpdC4KPj4KPj4gQmVj YXVzZSBvZiB0aGlzLCB0aGUgbmVnYXRpdmUtZGVmaWNpdCBzdGF0aW9uIHdvbid0IGJlIHRocm90 dGxlZCwgYW5kIHdlCj4+IHdvbid0IGdldCBmYWlybmVzcy4KPj4KPj4gSG93IG1hbnkgZnJhbWVz IHdpbGwgbXQ3NiBxdWV1ZSB1cCBiZWxvdyB0aGUgZHJpdmVyIHBvaW50PyBJLmUuLCBob3cKPj4g bXVjaCBidXJzdGluZXNzIGFyZSB5b3UgZXhwZWN0aW5nIHRoaXMgd2lsbCBpbnRyb2R1Y2Ugb24g dGhhdCBkcml2ZXI/Cj4+Cj4+IFRha2luZyBhIHN0ZXAgYmFjaywgaXQncyBjbGVhciB0aGF0IGl0 IHdvdWxkIGJlIGdvb2QgdG8gYmUgYWJsZSB0bwo+PiBkZXF1ZXVlIHBhY2tldHMgdG8gbXVsdGlw bGUgU1RBcyBhdCBvbmNlICh3ZSBuZWVkIHRoYXQgZm9yIE1VLU1JTU8gb24KPj4gYXRoMTBrIGFz IHdlbGwpLiBIb3dldmVyLCBJIGRvbid0IHRoaW5rIHdlIGNhbiBkbyB0aGF0IHdpdGggdGhlCj4+ IHJvdW5kLXJvYmluIGZhaXJuZXNzIHNjaGVkdWxlcjsgc28gd2UgYXJlIGdvaW5nIHRvIG5lZWQg YSBkaWZmZXJlbnQKPj4gYWxnb3JpdGhtLiBJICp0aGluayogaXQgbWF5IGJlIHBvc3NpYmxlIHRv IGRvIHRoaXMgd2l0aCBhIHZpcnR1YWwtdGltZQo+PiBzY2hlZHVsZXIsIGJ1dCBJIGhhdmVuJ3Qg c2F0IGRvd24gYW5kIHdvcmtlZCBvdXQgdGhlIGRldGFpbHMgeWV0Li4uCj4KPiBUaGUgYW5zd2Vy IHRvIHdoaWNoIGRpZCBub3QgZml0IG9uIHRoZSBtYXJnaW5zIG9mIHlvdXIgdGhlc2lzLiA6KQo+ Cj4gSSB0b28gaGF2ZSBiZWVuIHRyeWluZyB0byBjb21lIHVwIHdpdGggYSBiZXR0ZXIgbWVhbnMg b2YgZ2FuZwo+IHNjaGVkdWxpbmcuLi4gZm9yIGFib3V0IDIgeWVhcnMgbm93LiBJbiB0ZXJtcyBv ZiBiaXRtYXBzIGl0IGxvb2tzIGEgYml0Cj4gbGlrZSBRRlEsIGJ1dCBob25lc3RseS4uLgoKSXQn cyBub3QgdGhlIGdhbmcgc2NoZWR1bGluZyB3ZSBuZWVkLCBkZWNpZGluZyB3aGljaCBkZXZpY2Vz IHRvIHNlbmQgdG8KYXQgb25jZSBpcyBnZW5lcmFsbHkgZG9uZSBpbiBmaXJtd2FyZSBhbnl3YXku IFdlIGp1c3QgbmVlZCB0byBiZSBhYmxlIHRvCmRlcXVldWUgcGFja2V0cyBmb3IgbW9yZSB0aGFu IG9uZSBzdGF0aW9uIHdoZW4gcG9zc2libGUuIEkgZG9uJ3QgdGhpbmsKd2UgbmVlZCB0aGUgZmFu Y3kgYml0bWFwIHN0dWZmIGZyb20gUUZRIHNpbmNlIHdlIGRvbid0IGhhdmUgdGhhdCBtYW55CnN0 YXRpb25zIHRvIHNjaGVkdWxlIGF0IG9uY2U7IHNvIHdlIGNhbiBwcm9iYWJseSBsaXZlIHdpdGgg Tyhsb2cobikpIGluCnRoZSBudW1iZXIgb2YgYWN0aXZlIHN0YXRpb25zLgoKPiBJcyB0aGVyZSBn b2luZyB0byBiZSBzb21lIHBvaW50IHdoZXJlIHdoYXRldmVyIHdlIGhhdmUgaGVyZSBpcwo+IHNp Z25pZmljYW50bHkgYmV0dGVyIHRoYW4gd2hhdCB3ZSBoYWQ/IE9yIG5vdCBzaWduaWZpY2FudGx5 IHdvcnNlPyBPcgo+IGhhbmR3YXZ5IGVub3VnaCB0byBmaXggdGhlIHJlc3Qgb25jZSBlbmxpZ2h0 ZW5tZW50IGFycml2ZXM/Cj4KPiBUaGUgcGVyZmVjdCBpcyB0aGUgZW5lbXkgb2YgdGhlIGdvb2Qu CgpXZWxsLCB3aGF0IHdlIGhhdmUgbm93IHdvcmtzIGZvciBhdGg5aywgd29ya3MgcmVhc29uYWJs eSB3ZWxsIGZvciBhdGgxMGsKaW4gcHVsbCBtb2RlLCBub3Qgc28gd2VsbCBmb3IgYXRoMTBrIGlu IHB1c2ggbW9kZSwgYW5kIHRoZW4gdGhlcmUncwpGZWxpeCcgY29tbWVudHMgaW4gdGhpcyB0aHJl YWQuLi4KCj4gSSdkIHJhdGhlciBsaWtlIHRoZSBpbnRlbCBmb2xrIHRvIGJlIHdlaWdoaW5nIGlu IG9uIHRoaXMgc3R1ZmYsIHRvbywKPiB0cnlpbmcgdG8gZ2V0IGFuIEFQSSByaWdodCByZXF1aXJl cyB1c2UgY2FzZXMuCgpKb2hhbm5lcyBoYXMgYWxyZWFkeSByZXZpZXdlZCBhIHByZXZpb3VzIHZl cnNpb24sIGFuZCBJIGRvIGJlbGlldmUgaGUKc2FpZCBoZSdkIHJldmlldyBpdCBhZ2FpbiBvbmNl IHdlIGhhdmUgY29udmVyZ2VkIG9uIHNvbWV0aGluZyA6KQoKLVRva2UKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmF0aDEwayBtYWlsaW5nIGxpc3QKYXRo MTBrQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1h bi9saXN0aW5mby9hdGgxMGsK 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, 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 07A73C43441 for ; Mon, 19 Nov 2018 22:44:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B6C9120851 for ; Mon, 19 Nov 2018 22:44:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=toke.dk header.i=@toke.dk header.b="C38HQoPp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6C9120851 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=toke.dk 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 S1731627AbeKTJKi (ORCPT ); Tue, 20 Nov 2018 04:10:38 -0500 Received: from mail.toke.dk ([52.28.52.200]:38287 "EHLO mail.toke.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730462AbeKTJKi (ORCPT ); Tue, 20 Nov 2018 04:10:38 -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=1542667484; bh=NSenRGaoRqBaT+BqUpssj0zo6bokX6V7DOHhvbh3cN0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=C38HQoPpJ/ZtXVjEb+OEpViQreS4FSdg71qOEGBtdZWYpMJHGY2VEhBImlQGT7X4q GIGKdRy7FN4nw+g4jRAOBsE1eB1y2C1A5AFHwGASqmrMqCAD2SLLeLBYtjZmMyrQqL fK2/LWXYPP6888lDnL6/18cSzGjx4U/kQNy9DOVYHUKqERbMssYsoiUqyNdByuRbNe +wAyywWJ6EQAcAlF1rhhdJewpKjQYgNMY8XJeKsW86i7E4QSTfP9+esMlDN2pr0KNA DBIMOCkFoS24g77vWkNi7+oTWKUk7gGNZaxUYmxoNpvJHAr89bGFbJtddt2jMbqRhU YkaWcmkJqhPhQ== To: Dave Taht 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 In-Reply-To: <878t1p2bqz.fsf@taht.net> 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> Date: Mon, 19 Nov 2018 14:44:43 -0800 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87muq4sn50.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 Dave Taht writes: > Toke H=C3=B8iland-J=C3=B8rgensen writes: > >> Felix Fietkau writes: >> >>> On 2018-11-14 18:40, Toke H=C3=B8iland-J=C3=B8rgensen 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. >>>>=20 >>>> 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. Th= is >>>> 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. >>>>=20 >>>> 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. We just need to be able to dequeue packets for more than one station when possible. 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. > 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... > 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 :) -Toke