From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1gHjpA-0003iC-7z for ath10k@lists.infradead.org; Wed, 31 Oct 2018 06:17:53 +0000 MIME-Version: 1.0 Date: Wed, 31 Oct 2018 14:17:40 +0800 From: yiboz@codeaurora.org Subject: Re: [PATCH 3/6] mac80211: Add airtime accounting and scheduling to TXQs In-Reply-To: <87woq2843q.fsf@toke.dk> References: <1540033534-11211-1-git-send-email-rmanohar@codeaurora.org> <1540033534-11211-4-git-send-email-rmanohar@codeaurora.org> <8736ssbxp9.fsf@toke.dk> <9c2b790132a9a89fecd7dd79dc67d891@codeaurora.org> <87woq2843q.fsf@toke.dk> Message-ID: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Cc: linux-wireless-owner@vger.kernel.org, linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, Rajkumar Manoharan 5ZyoIDIwMTgtMTAtMjggMjM6NDjvvIxUb2tlIEjDuGlsYW5kLUrDuHJnZW5zZW4g5YaZ6YGT77ya Cj4gUmFqa3VtYXIgTWFub2hhcmFuIDxybWFub2hhckBjb2RlYXVyb3JhLm9yZz4gd3JpdGVzOgo+ IAo+PiBPbiAyMDE4LTEwLTI2IDA3OjE2LCBUb2tlIEjDuGlsYW5kLUrDuHJnZW5zZW4gd3JvdGU6 Cj4+PiBSYWprdW1hciBNYW5vaGFyYW4gPHJtYW5vaGFyQGNvZGVhdXJvcmEub3JnPiB3cml0ZXM6 Cj4+PiAKPj4+PiBGcm9tOiBUb2tlIEjDuGlsYW5kLUrDuHJnZW5zZW4gPHRva2VAdG9rZS5kaz4K Pj4gWy4uLl0KPj4+PiAgCXU4IG1heF9uYW5fZGVfZW50cmllczsKPj4+PiAgCXU4IHR4X3NrX3Bh Y2luZ19zaGlmdDsKPj4+PiArCXUzMiBhaXJ0aW1lX3dlaWdodDsKPj4+PiAgfTsKPj4+IAo+Pj4g VGhpcyBkb2Vzbid0IG1ha2Ugc2Vuc2UuIEFpcnRpbWUgd2VpZ2h0cyBjYW4gYmUgc2V0IGJ5IHVz ZXJzcGFjZSwgc28KPj4+IGV2ZW4gaWYgYSBkcml2ZXIgc2V0cyBhbm90aGVyIGRlZmF1bHQgaXQg aXMgbm90IGd1YXJhbnRlZWQgdG8gYmUKPj4+IGhvbm91cmVkLiBTbyB3aGF0J3MgdGhlIHBvaW50 Pwo+Pj4gCj4+IFRoZSByZWFzb24gZm9yIGRyaXZlciBzcGVjaWZpYyBkZWZhdWx0IGlzIHRvIGF2 b2lkIHBlcmZvcm1hbmNlIGltcGFjdAo+PiBpbiBhdGgxMGsgd2hlbiB0aGUgdXNlciBpcyB1c2lu ZyB2YW5pbGxhIGF0aDEwayB3aXRoIGRlZmF1bHQgYWlydGltZS4KPj4gQXMgSSBtZW50aW9uZWQg ZWFybGllciwgbWFjODAyMTEgZGVmYXVsdCAoMjU2dXMpIGlzIHRvbyBsb3cgZm9yIDExYWMKPj4g ZGV2aWNlcyBlc3BlY2lhbGx5IHdpdGggZHJpdmVyIGlzIGJ1cnN0aW5nIGFnZ3JlZ2F0aW9uLgo+ PiAKPj4gWWVzLiBJIGRvIHVuZGVyc3RhbmQgdGhlIHVzZXIgY2FuIGNoYW5nZSBhaXJ0aW1lIGF0 IGFueXRpbWUgYnV0IEl0Cj4+IG11c3QgYmUgbm90ZWQgdGhhdCBkaWZmZXJlbnQgYWlydGltZSB3 ZWlnaHQgd2lsbCByZXN1bHQgaW4gZGlmZmVyZW50Cj4+IHRocm91Z2hwdXQuIElNSE8gdGhlIGRl ZmF1bHRzIHNob3VsZCBub3QgaW1wYWN0IGN1cnJlbnQgYmVuY2htYXJrLgo+PiBPdGhlcndpc2Ug aXQgd2lsbCBiZSBhbGFybWVkIGFzIHJlZ3Jlc3Npb24gbGF0ZXIuIGlzbid0IGl0Pwo+IAo+IE15 IHBvaW50IGlzIHRoYXQgaWYgdGhlIHVzZXIgaGFzIHRvIGtub3cgdGhlIGltcGxlbWVudGF0aW9u LXNwZWNpZmljCj4gbGltaXRhdGlvbnMgb2YgZWFjaCBkcml2ZXIgYmVmb3JlIHNldHRpbmcgYSB3 ZWlnaHQsIHRoZW4gaXQncyBub3QgYQo+IHBhcnRpY3VsYXJseSBmcmllbmRseSBBUEkuIEkgdGhp bmsgd2Ugc2hvdWxkIGJlIGFibGUgdG8gZG8gYmV0dGVyIHRoYW4KPiB0aGF0Li4uCj4gCj4+PiBT byBzaW5jZSB3ZSdyZSByb3RhdGluZyB0aGUgcXVldWUgb24gZXZlcnkgY2FsbCB0byB0aGUgZnVu Y3Rpb24sIEknbQo+Pj4gd29uZGVyaW5nIGlmIHRoaXMgYWN0dWFsbHkgc3VjY2VlZHMgaW4gdGhy b3R0bGluZyB0aGUgc2xvdyBzdGF0aW9uJ3MKPj4+IGFpcnRpbWUgdXNhZ2UgZW5vdWdoIHRvIGFj aGlldmUgZmFpcm5lc3M/IFNvIEknbGwgYXNrIGFnYWluOiBEaWQgeW91Cj4+PiB0ZXN0IHRoZSBm YWlybmVzcyBwZXJmb3JtYW5jZSwgYW5kIGhvdz8KPj4+IAo+PiBXZSBhcmUgY29sbGVjdGluZyBk YXRhIG9mIG1peGVkIGNsaWVudHMgKDExYWMsIDExbiBhbmQgbGVnYWN5KSBrZWVwaW5nCj4+IHRo ZW0gYXQgc2FtZSBkaXN0YW5jZSBhbmQgZGlmZmVyZW50IGRpc3RhbmNlLiBTbyB0aGF0IGxvd2Vy IHJhdGUKPj4gY2xpZW50cyB3aWxsIGludGVyZmVyZSBoaWdoZXIgTUNTIHJhdGUgc3RhdGlvbi4g QWxzbyBjb25maWd1cmluZwo+PiBkaWZmZXJlbnQgYWlydGltZSB3ZWlnaHQgZm9yIGVhY2ggc3Rh dGlvbnMgc28gdGhhdCB0aHJvdHRsaW5nIGxvdyByYXRlCj4+IGNsaWVudHMgbW9yZSBzaG91bGQg aGVscCBoaWdoZXIgcGVyZm9ybWluZyhiZXR0ZXIgTUNTKSBjbGllbnRzLgo+PiAKPj4gQnkgYWxs b3dpbmcgZGlmZmVyZW50IGFpcnRpbWUgZm9yIGVhY2ggc3RhdGlvbnMsIHRoZSB1c2VyIGNhbiBj b250cm9sCj4+IGd1ZXN0IG5ldHdvcmsgb3ZlciBwcmltYXJ5IG5ldHdvcmsuIEFsc28gSXQgaGVs cGVkIHRvIGltcHJvdmUKPj4gcGVyZm9ybWFuY2Ugb2YgcHJlZmVycmVkIHN0YXRpb24gYW5kIGFs Z28uIHRvIGNvbnRyb2wgc3RhdGlvbiBpcyBnaXZlbgo+PiB0byBjbG91ZCBvciB1c2VyIGFwcGxp Y2F0aW9uLgo+PiAKPj4gQXMgb2Ygbm93LCBXZSBhcmUgdGVzdGluZyB3aXRoIDQgMTFhYyBjbGll bnRzIG9mIHNhbWUgZGlzdGFuY2UuIEFuZAo+PiBjb2xsZWN0aW5nIHRoZSBwZXJmb3JtYW5jZSBk YXRhIGluIG11bHRpcGxlIGl0ZXJhdGlvbi4gQmVsb3cgYXJlCj4+IGN1cnJlbnQgZGF0YSBvZiBz dGF0aW9uJ3MgcGVyZm9ybWFuY2UgKE1icHMpIGFnYWluc3QgYWlydGltZSB3ZWlnaHQuCj4+IAo+ PiBhaXJ0aW1lICAgc3RhdGlvbjEoJWFpcnRpbWUpICBzdGF0aW9uMiAgICAgc3RhdGlvbjMgICAg ICAgc3RhdGlvbjQKPj4gKE1icHMpCj4+IAo+PiBObyBBVEYgICAgICAxODIgICAgICAgICAgICAg ICAxNjggICAgICAgICAgMTY2ICAgICAgICAgICAgMTY5Cj4+IAo+PiA0bXMgICAgICAgICAxNzAg KDEwMCUpICAgICAgICAxNjQgKDEwMCUpICAgMTg1ICAoMTAwJSkgICAgMTc1ICgxMDAlKQo+PiAK Pj4gNG1zICAgICAgICAgMjc3ICg3MCUpICAgICAgICAgMTE1ICgxMCUpICAgIDEwMyAoMTAlKSAg ICAgIDEwNSAoMTAlKQo+PiAKPj4gNG1zICAgICAgICAgMjIzICg0MCUpICAgICAgICAgMjE0ICg0 MCUpICAgIDEwOSAoMTAlKSAgICAgICA5NCAoMTAlKQo+PiAKPj4gNG1zICAgICAgICAgMzM3ICg5 MCUpICAgICAgICAgMTgyICg4JSkgICAgICAyMyAoMSUpICAgICAgICAzMCAoMSUpCj4gCj4gU28g dGhpcyBsb29rcyBsaWtlIGl0J3MgZG9pbmcgKnNvbWV0aGluZyosIGJ1dCBub3QgbGlrZSBpdCdz IHN1Y2NlZWRpbmcKPiBpbiBhY2hpZXZpbmcgdGhlIHNldCBwZXJjZW50YWdlcy4gRGlkIHlvdSBj aGVjayBpZiB0aGUgYWN0dWFsIGFpcnRpbWUKPiB2YWx1ZXMgKGluIGRlYnVnZnMpIGNvcnJlc3Bv bmRzIHRvIHRoZSBjb25maWd1cmVkIHdlaWdodHM/Cj4gCj4+IAo+PiAgICAgICAgICAgICAgU1RB MSgxMWFjKSAgU1RBMiAoMTFuKSAgU1RBMygxMWEpCj4+ICAgICAgICAgICAgICA9PT09PT09PT09 ICA9PT09PT09PT09ICA9PT09PT09PT0KPj4gCj4+IE5vIEFURiAgICAgICAyMjUgICAgICAgICAx NjYgICAgICAgICAzLjUKPj4gCj4+IEFURiAoNG1zKSAgICAyMzQgICAgICAgICAxNTEgICAgICAg ICAzLjUKPiAKPiBUaGlzIGFsc28gc2hvd3MgbGlrZSBBVEYgaGFzIG5vIGVmZmVjdD8KPiAKPj4+ IEFsc28sIHRha2luZyBhIHN0ZXAgYmFjazoKPj4+IAo+Pj4gV2l0aCB0aGlzLCB3ZSdyZSBkb2lu ZyBsb3RzIG9mIHdvcmsgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGhhcmR3YXJlJ3MKPj4+IHJvdW5k LXJvYmluIHNjaGVkdWxpbmcgcXVldWUgbGluZXMgdXAgd2l0aCBtYWM4MDIxMTsgc28gaWYgd2Ug ZG8gdGhpcwo+Pj4gYW55d2F5LCB3aHkgY2FuJ3Qgd2UganVzdCBjb250cm9sIHRoZSBvcmRlciBk aXJlY3RseSBmcm9tIG1hYzgwMjExCj4+PiAod2hpY2ggaXMgd2hhdCB3ZSBkbyB3aXRoIHRoZSBv dGhlciBuZXh0X3R4cSgpIEFQSSk/Cj4+PiAKVG9rZSBhbmQgUmFqLAoKSG93IGFib3V0IHRyZWF0 aW5nIGFueSB0eHFzIGJlZm9yZSB0aGUgdHhxIHRoYXQgRlcgYXNrZWQgZm9yIGluIApwdXNoLXB1 bGwgbW9kZQphcyBwZW5kaW5nIHR4cXM/IFRoZW4gd2UgY2FuIGRlcXVldWUgYW5kIHJlb3JkZXIg dGhlbS5BbmQgYWlydGltZSB3ZWlnaHQgCm5lZWQKdG8gYmUgdHVuZWQgdG8gbWFrZSBzdXJlIGl0 IHdvbid0IGNvc3QgdG9vIG11Y2ggdGltZS4gQWZ0ZXIgdGhhdCwgY2hlY2sgCnRoZSB0eHEKRlcg d2lzaGVzIHRvIGZldGNoIGluIHR4cV9tYXlfdHJhbnNtaXQuCgpJcyB0aGlzIHdheSBhYmxlIHRv IGFjaGlldmUgZmFpcm5lc3MgYW5kIGxpbmUgdXAgd2l0aCBtYWM4MDIxMT8KQWxzbywgd2UgbWF5 IG5lZWQgdG8gY29uc2lkZXIgaWYgRlcgc3VwcG9ydHMgaW4gdGhpcyB3YXkuCgo+PiBUaGUgb25s eSB3YXkgdG8gZW5mb3JjZSBtYWM4MDIxMSBvcmRlcmluZyBpbiBhdGgxMGsgaXMgdG8gZGlzYWJs ZSBwdWxsCj4+IG1vZGUgaW4gZmlybXdhcmUgYW5kIGFsd2F5cyBvcGVyYXRlcyBpbiBwdXNoIG1v ZGUgc2ltaWxhciB0byBhdGg5ay4KPiAKPiBBbmQgSSBhc3N1bWUgdGhhdCBpcyBub3QgdG9vIGxp a2VseSB0byBoYXBwZW4sIG9yPyBXaGF0IGlzIHRoZSBiZW5lZml0Cj4gb2YgcHVsbCBtb2RlIGF0 IHRoZSBmaXJtd2FyZSBsZXZlbD8KPiAKPiAtVG9rZQoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KYXRoMTBrIG1haWxpbmcgbGlzdAphdGgxMGtAbGlzdHMu aW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2F0aDEwawo= 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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 C5FD5C0044C for ; Wed, 31 Oct 2018 06:17:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7D53120821 for ; Wed, 31 Oct 2018 06:17:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="Dkf5JAJz"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="atqj50ru" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D53120821 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org 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 S1729061AbeJaPOY (ORCPT ); Wed, 31 Oct 2018 11:14:24 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:52042 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726287AbeJaPOY (ORCPT ); Wed, 31 Oct 2018 11:14:24 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id A60E6601B4; Wed, 31 Oct 2018 06:17:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1540966661; bh=GzBuBmK8VPczhL7EZnxGYp3SKg0UuEhu21xxke46Nlg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Dkf5JAJzEb27TU5esyUDuvpjPj7YGOhQvQMHc0Bf7C4/oNUBWpfCxBjJO+tz7BoFS 89M+h+QXWSPVmIeg8kE6u55HXJZicSF8L4iBN+amZZ9Jy1iSNecPooZKWOW8xepucM WNuDb8Lt6ieOs9gKm2guRooRfUQ60R0tkA+/Ctps= Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id C09B1605A2; Wed, 31 Oct 2018 06:17:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1540966660; bh=GzBuBmK8VPczhL7EZnxGYp3SKg0UuEhu21xxke46Nlg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=atqj50ruYGU/vQQFy7mm/yAkDeuDxEgTpeeswLBzGT6yTdHhwcKr3R4t7tkukvYb/ rQXAC3oY6ZdcHCrD8zV2oPCDZmA6QWosIG+V5MXl6tKYPmGHMH5Ke30XKeSReOsPgC k9YLCEIhnnmkWL3+E46cI8vXiuvzUPlLZeZxINaI= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 31 Oct 2018 14:17:40 +0800 From: yiboz@codeaurora.org To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Cc: Rajkumar Manoharan , linux-wireless@vger.kernel.org, ath10k@lists.infradead.org, linux-wireless-owner@vger.kernel.org Subject: Re: [PATCH 3/6] mac80211: Add airtime accounting and scheduling to TXQs In-Reply-To: <87woq2843q.fsf@toke.dk> References: <1540033534-11211-1-git-send-email-rmanohar@codeaurora.org> <1540033534-11211-4-git-send-email-rmanohar@codeaurora.org> <8736ssbxp9.fsf@toke.dk> <9c2b790132a9a89fecd7dd79dc67d891@codeaurora.org> <87woq2843q.fsf@toke.dk> Message-ID: X-Sender: yiboz@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org 在 2018-10-28 23:48，Toke Høiland-Jørgensen 写道： > Rajkumar Manoharan writes: > >> On 2018-10-26 07:16, Toke Høiland-Jørgensen wrote: >>> Rajkumar Manoharan writes: >>> >>>> From: Toke Høiland-Jørgensen >> [...] >>>> u8 max_nan_de_entries; >>>> u8 tx_sk_pacing_shift; >>>> + u32 airtime_weight; >>>> }; >>> >>> This doesn't make sense. Airtime weights can be set by userspace, so >>> even if a driver sets another default it is not guaranteed to be >>> honoured. So what's the point? >>> >> The reason for driver specific default is to avoid performance impact >> in ath10k when the user is using vanilla ath10k with default airtime. >> As I mentioned earlier, mac80211 default (256us) is too low for 11ac >> devices especially with driver is bursting aggregation. >> >> Yes. I do understand the user can change airtime at anytime but It >> must be noted that different airtime weight will result in different >> throughput. IMHO the defaults should not impact current benchmark. >> Otherwise it will be alarmed as regression later. isn't it? > > My point is that if the user has to know the implementation-specific > limitations of each driver before setting a weight, then it's not a > particularly friendly API. I think we should be able to do better than > that... > >>> So since we're rotating the queue on every call to the function, I'm >>> wondering if this actually succeeds in throttling the slow station's >>> airtime usage enough to achieve fairness? So I'll ask again: Did you >>> test the fairness performance, and how? >>> >> We are collecting data of mixed clients (11ac, 11n and legacy) keeping >> them at same distance and different distance. So that lower rate >> clients will interfere higher MCS rate station. Also configuring >> different airtime weight for each stations so that throttling low rate >> clients more should help higher performing(better MCS) clients. >> >> By allowing different airtime for each stations, the user can control >> guest network over primary network. Also It helped to improve >> performance of preferred station and algo. to control station is given >> to cloud or user application. >> >> As of now, We are testing with 4 11ac clients of same distance. And >> collecting the performance data in multiple iteration. Below are >> current data of station's performance (Mbps) against airtime weight. >> >> airtime station1(%airtime) station2 station3 station4 >> (Mbps) >> >> No ATF 182 168 166 169 >> >> 4ms 170 (100%) 164 (100%) 185 (100%) 175 (100%) >> >> 4ms 277 (70%) 115 (10%) 103 (10%) 105 (10%) >> >> 4ms 223 (40%) 214 (40%) 109 (10%) 94 (10%) >> >> 4ms 337 (90%) 182 (8%) 23 (1%) 30 (1%) > > So this looks like it's doing *something*, but not like it's succeeding > in achieving the set percentages. Did you check if the actual airtime > values (in debugfs) corresponds to the configured weights? > >> >> STA1(11ac) STA2 (11n) STA3(11a) >> ========== ========== ========= >> >> No ATF 225 166 3.5 >> >> ATF (4ms) 234 151 3.5 > > This also shows like ATF has no effect? > >>> Also, taking a step back: >>> >>> With this, we're doing lots of work to make sure that the hardware's >>> round-robin scheduling queue lines up with mac80211; so if we do this >>> anyway, why can't we just control the order directly from mac80211 >>> (which is what we do with the other next_txq() API)? >>> Toke and Raj, How about treating any txqs before the txq that FW asked for in push-pull mode as pending txqs? Then we can dequeue and reorder them.And airtime weight need to be tuned to make sure it won't cost too much time. After that, check the txq FW wishes to fetch in txq_may_transmit. Is this way able to achieve fairness and line up with mac80211? Also, we may need to consider if FW supports in this way. >> The only way to enforce mac80211 ordering in ath10k is to disable pull >> mode in firmware and always operates in push mode similar to ath9k. > > And I assume that is not too likely to happen, or? What is the benefit > of pull mode at the firmware level? > > -Toke