Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

>> 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 >

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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. +

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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,

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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 >>

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

Re: [RFC/RFT] mac80211: implement fq_codel for software queuing

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

[RFC/RFT] mac80211: implement fq_codel for software queuing

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