MIME-Version: 1.0
In-Reply-To: <51307F80.4010202@openwrt.org>
References: <1360329197-72631-1-git-send-email-nbd@openwrt.org>
	<20757.1753.863278.858198@gargle.gargle.HOWL>
	<511508A6.8020104@openwrt.org>
	<CAMcMvsjE=NNqt_q=vepZbFE8vwLypN2qZwyXg=aCBj3vvYOpMw@mail.gmail.com>
	<51152D9E.1040106@openwrt.org>
	<20130227192030.GW12537@pogo>
	<CAJ-VmonSQi1SZVrkvcuS8dubqSAy8s1RCGJounL1EA23z3FXzw@mail.gmail.com>
	<512ECE01.8010102@openwrt.org>
	<20130228114724.GB16369@localhost>
	<512F5709.60907@openwrt.org>
	<CAJ-Vmom_YFWOU5+eAYv=mnUKVOuP6n3OO32GbO7AcwTgi5-HwQ@mail.gmail.com>
	<512FAB01.2050104@openwrt.org>
	<CAJ-Vmokr4_k5QKrvVGU-1pG0Y07iW9evyRkj_U4-zQ5TH1ZHBQ@mail.gmail.com>
	<51307F80.4010202@openwrt.org>
Date: Fri, 1 Mar 2013 02:22:29 -0800
Message-ID: <CAJ-Vmok9-dmC5-vhHA1DE_KW6mp7P3tijrSz-3D45jjQthbcCA@mail.gmail.com> (sfid-20130301_112234_794702_A990E66F)
Subject: Re: [RFC] ath9k: remove ath9k_rate_control
From: Adrian Chadd <adrian@freebsd.org>
To: Felix Fietkau <nbd@openwrt.org>
Cc: Bob Copeland <me@bobcopeland.com>,
	"Luis R. Rodriguez" <rodrigue@qca.qualcomm.com>,
	Paul Stewart <pstew@google.com>,
	Sujith Manoharan <sujith@msujith.org>,
	linux-wireless <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset=ISO-8859-1
Sender: linux-wireless-owner@vger.kernel.org

On 1 March 2013 02:14, Felix Fietkau <nbd@openwrt.org> wrote:

>> Having access to schedule which peer and how much to send to each peer
>> would be nice. Stuff like "peer X only can have up to x ms in this WME
>> class this round", so you don't have a busy, close peer monopolising
>> the air. It also means you can start doing smart things with far away
>> peers who retransmit a lot - they're likely tying up a lot of airtime.
>>
>> None of this is new. It's just, you know, new to open source. :-)

> In my opinion this doesn't really belong into a rate control module.
> There should be a tx scheduling API to take care of this. Before I
> implement something like this, I plan on exposing all per-station driver
> queues to mac80211. This is necessary for a few other things anyway,
> e.g. unifying software aggregation logic and fixing its buffer management.

Sure, but then some more clever tricks end up being difficult to
implement. For example, knowing if a client is tying up too much
airtime at the given rate and whether to back them off for a bit. Or
to use smaller aggregation limits for certain clients because your'e
trying to be "fairer" when trying to keep latency low. That kind of
thing.

I think "rate control" should likely be expanded to "tx scheduling" as
a whole, rather than sitting as a separate thing that just selects the
rate for a node who has already been chosen to transmit.


Adrian