On 10 March 2016 at 19:57, Dave Taht wrote:
>>> regular fq_codel uses 1024 and there has not been much reason to
>>> change it. In the case of an AP which has more limited memory, 256 or
>>> 1024 would be a good setting, per station. I'd stick to 1024 for now.
>>
>> Do note that the 4096 is shared
>> regular fq_codel uses 1024 and there has not been much reason to
>> change it. In the case of an AP which has more limited memory, 256 or
>> 1024 would be a good setting, per station. I'd stick to 1024 for now.
>
> Do note that the 4096 is shared _across_ station-tid queues. It is not
> per-stat
On 8 March 2016 at 14:14, Bob Copeland 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 mac8
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_rat
On 8 March 2016 at 00:06, Dave Taht wrote:
> Dear Michal:
>
> Going through this patchset... (while watching it compile)
>
>
> + if (!local->hw.txq_cparams.target)
> + local->hw.txq_cparams.target = MS2TIME(5);
>
> MS2TIME(20) for now and/or add something saner to this than !*b
Michal Kazior writes:
>> With large values for flows_cnt, fq, dominates, for small values, aqm
>> does. We did quite a lot of testing at 16 and 32 queues in the early
>> days, with pretty good results, except when we didn't. Cake went whole
>> hog with an 8 way set associative hash leading to "ne
On 7 March 2016 at 19:28, Dave Taht wrote:
> On Mon, Mar 7, 2016 at 9:14 AM, Avery Pennarun wrote:
>> On Mon, Mar 7, 2016 at 11:54 AM, Dave Taht wrote:
[...]
>>> the underlying code needs to be striving successfully for per-station
>>> airtime fairness for this to work at all, and the driver/car
On 8 March 2016 at 00:06, Dave Taht wrote:
> Dear Michal:
>
> Going through this patchset... (while watching it compile)
>
>
> + if (!local->hw.txq_cparams.target)
> + local->hw.txq_cparams.target = MS2TIME(5);
>
> MS2TIME(20) for now and/or add something saner to this than !*b
Dear Michal:
Going through this patchset... (while watching it compile)
+ if (!local->hw.txq_cparams.target)
+ local->hw.txq_cparams.target = MS2TIME(5);
MS2TIME(20) for now and/or add something saner to this than !*backlog
target will not be a constant in the long run.
+
On Mon, Mar 7, 2016 at 9:14 AM, Avery Pennarun wrote:
> On Mon, Mar 7, 2016 at 11:54 AM, Dave Taht wrote:
>> If I can just get a coherent patch set that I can build, I will gladly
>> join you on the testing ath9k in particular... can probably do ath10k,
>> too - and do a bit of code review... thi
On 03/07/2016 07:15 PM, Avery Pennarun wrote:
> On Mon, Mar 7, 2016 at 11:54 AM, Dave Taht wrote:
>> If I can just get a coherent patch set that I can build, I will gladly
>> join you on the testing ath9k in particular... can probably do ath10k,
>> too - and do a bit of code review... this week.
On Mon, Mar 7, 2016 at 11:54 AM, Dave Taht wrote:
> If I can just get a coherent patch set that I can build, I will gladly
> join you on the testing ath9k in particular... can probably do ath10k,
> too - and do a bit of code review... this week. it's very exciting
> watching all this activity...
>
If I can just get a coherent patch set that I can build, I will gladly
join you on the testing ath9k in particular... can probably do ath10k,
too - and do a bit of code review... this week. it's very exciting
watching all this activity...
but I confess that I've totally lost track of what set of t
On Mon, Mar 7, 2016 at 10:09 AM, Felix Fietkau wrote:
> On 2016-03-07 15:05, Avery Pennarun wrote:
>> On Fri, Mar 4, 2016 at 1:32 AM, Michal Kazior
>> wrote:
>>> On 4 March 2016 at 03:48, Tim Shepard wrote:
>>> [...]
(I am interested in knowing what other mac80211 drivers have been
m
On 2016-03-07 15:05, Avery Pennarun wrote:
> On Fri, Mar 4, 2016 at 1:32 AM, Michal Kazior wrote:
>> On 4 March 2016 at 03:48, Tim Shepard wrote:
>> [...]
>>> (I am interested in knowing what other mac80211 drivers have been
>>> modified to use the mac80211 intermediate software queues. I know
On Fri, Mar 4, 2016 at 1:32 AM, Michal Kazior wrote:
> On 4 March 2016 at 03:48, Tim Shepard wrote:
> [...]
>> (I am interested in knowing what other mac80211 drivers have been
>> modified to use the mac80211 intermediate software queues. I know
>> Michal mentioned he has patches for ath10k t
On 4 March 2016 at 03:48, Tim Shepard wrote:
[...]
> (I am interested in knowing what other mac80211 drivers have been
> modified to use the mac80211 intermediate software queues. I know
> Michal mentioned he has patches for ath10k that are not yet released,
> and I know Felix is finishing up
If you want to try out Michal's patch you'll need a mac80211 driver
that uses the new intermediate queues.
I just submitted a PATCH RFC/RFT to modify ath9k to use the new
intermediate software queues. There are very few (zero or close to
zero) drivers in linux which do that, and Michal's patch
On Tue, Mar 1, 2016 at 11:38 PM, Michal Kazior wrote:
> On 1 March 2016 at 15:02, Johannes Berg wrote:
>> On Fri, 2016-02-26 at 14:09 +0100, Michal Kazior wrote:
>>>
>>> +typedef u64 codel_time_t;
>>
>> Do we really need this? And if yes, does it have to be in the public
>> header file? Why a typ
On 1 March 2016 at 15:02, Johannes Berg wrote:
> On Fri, 2016-02-26 at 14:09 +0100, Michal Kazior wrote:
>>
>> +typedef u64 codel_time_t;
>
> Do we really need this? And if yes, does it have to be in the public
> header file? Why a typedef anyway?
Hmm.. I don't think it's strictly necessary. I ju
On Fri, 2016-02-26 at 14:09 +0100, Michal Kazior wrote:
>
> +typedef u64 codel_time_t;
Do we really need this? And if yes, does it have to be in the public
header file? Why a typedef anyway?
> - * @txq_ac_max_pending: maximum number of frames per AC pending in
> all txq
> - * entries for a vif
On 26 February 2016 at 17:48, Felix Fietkau wrote:
[...]
>> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
>> index af584f7cdd63..f42f898cb8b5 100644
>> --- a/net/mac80211/tx.c
>> +++ b/net/mac80211/tx.c
>> + [...]
>> +static void ieee80211_txq_enqueue(struct ieee80211_local *local,
>> +
On 2016-02-26 14:09, Michal Kazior wrote:
> Since 11n aggregation become important to get the
> best out of txops. However aggregation inherently
> requires buffering and queuing. Once variable
> medium conditions to different associated stations
> is considered it became apparent that bufferbloat
Since 11n aggregation become important to get the
best out of txops. However aggregation inherently
requires buffering and queuing. Once variable
medium conditions to different associated stations
is considered it became apparent that bufferbloat
can't be simply fought with qdiscs for wireless
driv
24 matches
Mail list logo
