[Make-wifi-fast] [PATCHv4 5/5] mac80211: add debug knobs for codel
michal.kazior at tieto.com
Fri May 6 02:33:07 EDT 2016
On 6 May 2016 at 07:51, Dave Taht <dave.taht at gmail.com> wrote:
> On Thu, May 5, 2016 at 10:27 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> On 5 May 2016 at 17:21, Dave Taht <dave.taht at gmail.com> wrote:
>>> On Thu, May 5, 2016 at 4:00 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
>>>> This adds a few debugfs entries to make it easier
>>>> to test, debug and experiment.
>>> I might argue in favor of moving all these (inc the fq ones) into
>>> their own dir, maybe "aqm" or "sqm".
>>> The mixture of read only stats and configuration vars is a bit confusing.
>>> Also in my testing of the previous patch, actually seeing the stats
>>> get updated seemed to be highly async or inaccurate. For example, it
>>> was obvious from the captures themselves that codel_ce_mark-ing was
>>> happening, but the actual numbers out of wack with the mark seen or
>>> fq_backlog seen. (I can go back to revisit this)
>> That's kind of expected since all of these bits are exposed as
>> separate debugfs entries/files. To avoid that it'd be necessary to
>> provide a single debugfs entry/file whose contents are generated on
>> open() while holding local->fq.lock. But then you could argue it
>> should contain all per-sta-tid info as well (backlog, flows, drops) as
>> well instead of having them in netdev*/stations/*/txqs.
> I have not had time to write up todays results to any full extent, but
> they were pretty spectacular.
> I have a comparison of the baseline ath10k driver vs your 3.5 patchset
> here on the second plot:
> The raw data is here:
It's probably good to explicitly mention that you test(ed) ath10k with
my RFC DQL patch applied. Without it the fqcodel benefits are a lot
(oh, and the "3.5" is pre-PATCHv4 before fq/codel split work:
> a note: quantum of the mtu (typically 1514) is a saner default than 300,
> (the older patch I had, set it to 300, dunno what your default is now).
I still use 300.
> and quantum 1514, codel target 5ms rather than 20ms for this test
> series was *just fine* (but more testing of the lower target is
I would keep 20ms for now until we get more test data. I'm mostly
concerned about MU performance on ath10k which requires significant
amount of buffering.
> quantum "300" only makes sense for very, very low bandwidths (say <
> 6mbits), in other scenarios it just eats extra cpu (5 passes through
> the loop to send a big packet) and disables
> the "new/old" queue feature which helps "push" new flows to flow
> balance. I'd default it to the larger value.
Perhaps this could be dynamically adjusted to match the slowest
station known to rate control in the future? Oh, and there's
More information about the Make-wifi-fast