From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 96E3F3B29E for ; Wed, 29 Aug 2018 06:33:56 -0400 (EDT) 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=1535538835; bh=lsBEANcFVE/XqGSmK6chrxb6aRV5sX/eY/UwLVPtnxM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Y3JH6tZltH6xjFqdRIxiBwjj/nhieKqbZzN7oChBQxD8+VVp0e7/5M67luJqruprq rGsQJYDZ642s+hoABpoxCKoV+SInp4cmRgiVO7DpPsW/uuo7sUyla/ikqo8EGO1eQP xxGKt2OK8QLjDLNenwHxcRzMBpMMUgRZqoMsT9r1ReOeaOaT1H/e6NQePhip8dZj0k hAewdMELtefK41dyHfdZhxxpcNu3KH1IvcfvfsbDJWikJlzVRtvEnylLakcfBGPziw Jf5Ot/r6M8NcE9GESPYViNeeMIXMyuxTzgtJWxPlcLHdKzoCYaQ+dQGKdOA3HNI+Bc WvnBuDQMHam+Q== To: Johannes Berg , linux-wireless@vger.kernel.org Cc: make-wifi-fast@lists.bufferbloat.net, Felix Fietkau In-Reply-To: <1535537670.5215.26.camel@sipsolutions.net> References: <153115421866.7447.6363834356268564403.stgit@alrua-x1> <153115422499.7447.2570671473822724496.stgit@alrua-x1> <1535528658.5215.19.camel@sipsolutions.net> <877ek94j66.fsf@toke.dk> <1535537670.5215.26.camel@sipsolutions.net> Date: Wed, 29 Aug 2018 12:33:55 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y3cp31ik.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [RFC v2 2/4] mac80211: Add airtime accounting and scheduling to TXQs X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 10:33:56 -0000 Johannes Berg writes: > On Wed, 2018-08-29 at 11:27 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> Hmm, the problem with a higher weight is that weight*quantum becomes the >> time each station is scheduled, so having a higher value means higher >> latency. This could be fixed by replacing the station weights with >> per-station quantums, but I felt that this was exposing an >> implementation detail in the API; if we ever change the enforcement >> mechanism to not be quantum-based (as may be necessary for MU-MIMO for >> instance), we'll have to convert values in the kernel. Whereas weights >> are a conceptual measure that is not tied to any particular >> implementation. > > Ok, but that's also an effect you should describe in the API for it. What's the right place to put that? In the netlink header file? > Perhaps then it should just be fractional? i.e. 8.8 bits or so?, so > the default would be 1.0 (0x0100) and then you could scale down to 0.5 > (0x0080) etc? Hmm, that's an interesting idea. I'll have to run some numbers to see how the precision holds up on various examples; but that would allow us to get rid of the quantum in the userspace API entirely, which is a good thing as far as I'm concerned! >> For the drivers that get airtime as part of TX completion, sure; but as >> I understand it, at least ath10k gets airtime information in out of band >> status reports, so there would need to be a callback for that in any >> case... > > Hmm, ok, but perhaps then we should also tie those to the existing > airtime things? Eh? Tie what to which existing airtime things? -Toke