[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+BoTQnwvGRhM3_-CT8-__nAAo8RmR51=G-7C1VcMFkSoTKUAg@mail.gmail.com>
Date: Tue, 8 Mar 2016 14:27:47 +0100
From: Michal Kazior <michal.kazior@...to.com>
To: Bob Copeland <me@...copeland.com>
Cc: Dave Taht <dave.taht@...il.com>,
linux-wireless <linux-wireless@...r.kernel.org>,
Johannes Berg <johannes@...solutions.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
Felix Fietkau <nbd@...nwrt.org>,
Tim Shepard <shep@...m.mit.edu>
Subject: Re: [RFC/RFT] mac80211: implement fq_codel for software queuing
On 8 March 2016 at 14:14, Bob Copeland <me@...copeland.com> wrote:
> On Tue, Mar 08, 2016 at 08:12:21AM +0100, Michal Kazior wrote:
>> However other drivers (e.g. ath10k) have offloaded rate control on
>> device. There's currently no way of doing this calculation. I was
>> thinking of drivers exporting tx_rate to mac80211 in some way - either
>> via a simple sta->tx_rate scalar that the driver is responsible for
>> updating, or a EWMA that driver updates (hopefully) periodically and
>> often enough. This should in theory at least allow an estimate how
>> much data on average you can fit into given time frame (e.g. txop, or
>> hardcoded 1ms).
>
> What about implementing ops->get_expected_throughput? This would be
> useful for mesh (both 11s and batman) as well since they need to
> estimate link quality to pick a path.
Oh, good point! I totally forgot about this because - in the back of
my head - I was convinced this is available only for minstrel. I guess
this could work as well.
MichaĆ
Powered by blists - more mailing lists