[Make-wifi-fast] net-next is next

[Make-wifi-fast] net-next is next

[Dave Taht]

I'm a little vague on the pieces missing as yet. I think?, still out
of tree are:

* Hooking up the ath9k to the intermediate queues code
* airtime fairness for the ath9k
* Ath10k has a partial revert for "some hardware" that disables the
intermediate queues code, but it's totally unclear "which hardware".
I'd hope that the "performance reasons" for this change have gone
away, and we could retest on the archer c7v2 and ubnt uap lite
platfporms.
* Ath10k got NAPI support, and I don't know what that means
* Codel "hack" for low rates

As for what's in lede.... ?

Aside from that, bunch O good thangs landed:

---------- Forwarded message ----------
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, Sep 30, 2016 at 9:14 AM
Subject: pull-request: mac80211-next 2016-09-30
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org


Hi Dave,

Last pull request before the merge window, since it's about to open :)
It seems that everyone finally agreed on the NAN (neighbor awareness
networking) APIs, so we have that, along with some other things.

Let me know if there's any problem.

Thanks,
johannes



The following changes since commit c13ed534b8db543e4d8ead3885f4b06585a5771c:

  Merge tag 'mac80211-next-for-davem-2016-09-16' of
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
(2016-09-18 22:29:08 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
tags/mac80211-next-for-davem-2016-09-30

for you to fetch changes up to bb42f2d13ffcd0baed7547b37d05add51fcd50e1:

  mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue
(2016-09-30 14:46:57 +0200)

----------------------------------------------------------------
This time around, we have
 * Neighbor Awareness Networking (NAN) APIs
 * a fix for a previous patch that caused memory corruption
   in wireless extensions key settings
 * beacon rate configuration for AP and mesh
 * memory limits for mac80211's internal TXQs
 * a (fairly involved) fix for the TXQ vs. crypto problems
 * direct cfg80211 driver API for WEP keys

----------------------------------------------------------------
Ayala Beker (9):
      cfg80211: add start / stop NAN commands
      mac80211: add boilerplate code for start / stop NAN
      cfg80211: add add_nan_func / del_nan_func
      cfg80211: allow the user space to change current NAN configuration
      cfg80211: provide a function to report a match for NAN
      cfg80211: Provide an API to report NAN function termination
      mac80211: implement nan_change_conf
      mac80211: Implement add_nan_func and rm_nan_func
      mac80211: Add API to report NAN function match

David Spinadel (1):
      cfg80211: Add support for static WEP in the driver

Johannes Berg (2):
      cfg80211: add checks for beacon rate, extend to mesh
      cfg80211: wext: really don't store non-WEP keys

Pedersen, Thomas (2):
      mac80211: add offset_tsf driver op and use it for mesh
      mac80211: mesh: decrease max drift

Purushottam Kushwaha (1):
      cfg80211: Add support to configure a beacon data rate

Toke Høiland-Jørgensen (5):
      mac80211: Move ieee802111_tx_dequeue() to later in tx.c
      fq.h: Port memory limit mechanism from fq_codel
      mac80211: Export fq memory limit information in debugfs
      mac80211: Set lower memory limit for non-VHT devices
      mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue

 include/net/cfg80211.h        |  223 +++++++-
 include/net/fq.h              |    3 +
 include/net/fq_impl.h         |    7 +-
 include/net/mac80211.h        |   75 +++
 include/uapi/linux/nl80211.h  |  270 ++++++++-
 net/mac80211/cfg.c            |  208 +++++++
 net/mac80211/chan.c           |    6 +
 net/mac80211/debugfs.c        |    8 +
 net/mac80211/debugfs_netdev.c |   12 +-
 net/mac80211/driver-ops.c     |   15 +
 net/mac80211/driver-ops.h     |   83 +++
 net/mac80211/ieee80211_i.h    |   26 +
 net/mac80211/iface.c          |   28 +-
 net/mac80211/main.c           |    8 +
 net/mac80211/mesh_sync.c      |   12 +-
 net/mac80211/offchannel.c     |    4 +-
 net/mac80211/rx.c             |    7 +-
 net/mac80211/sta_info.c       |   10 +-
 net/mac80211/trace.h          |  159 ++++++
 net/mac80211/tx.c             |  351 ++++++++----
 net/mac80211/util.c           |   61 ++-
 net/wireless/chan.c           |    2 +
 net/wireless/core.c           |   35 ++
 net/wireless/core.h           |    7 +-
 net/wireless/ibss.c           |    5 +-
 net/wireless/mlme.c           |    1 +
 net/wireless/nl80211.c        | 1220 ++++++++++++++++++++++++++++++++---------
 net/wireless/rdev-ops.h       |   58 ++
 net/wireless/sme.c            |    6 +-
 net/wireless/trace.h          |   90 +++
 net/wireless/util.c           |   30 +-
 net/wireless/wext-compat.c    |   14 +-
 net/wireless/wext-sme.c       |    2 +-
 33 files changed, 2648 insertions(+), 398 deletions(-)


-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Make-wifi-fast] net-next is next

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht@gmail.com> writes:

> I'm a little vague on the pieces missing as yet. I think?, still out
> of tree are:

Don't see anything missing from the list that I have been working on. Of
the things I have:

> * Hooking up the ath9k to the intermediate queues code

I expect Kalle to add this sometime during the upcoming merge window
(which opens tomorrow, according to the PHB crystal ball:
http://phb-crystal-ball.org/).

> * airtime fairness for the ath9k

Haven't submitted a new version of this since the other things went in.
While the basic scheduler works well, there are still some things to
work out before making a serious attempt at upstreaming it (most notably
the interaction with the hardware QoS queues). Also, moving parts of the
code into mac80211 would make it easier to re-use in other drivers. Not
sure which parts, though.

> * Codel "hack" for low rates

This still needs to be solved, but the hack I posted previously was just
that: A hack. I think a different approach is needed.

> As for what's in lede.... ?

LEDE has the previous version of the mac80211 fix and the ath9k patch to
enable the TXQ.

-Toke

Re: [Make-wifi-fast] net-next is next

[Dave Taht]

Michal says: "for qca988x and latest kernel you'll need to
revert one of my patches[1] that removed wake_tx_queue support for
older devices (due to some perf regressions on low-end systems they
were installed in; some people kept complaining about it)."

[1]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath10k?id=4ca1807815aa6801aaced7fdefa9edacc2521767

On Sat, Oct 1, 2016 at 11:09 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> I'm a little vague on the pieces missing as yet. I think?, still out
>> of tree are:
>
> Don't see anything missing from the list that I have been working on. Of
> the things I have:
>
>> * Hooking up the ath9k to the intermediate queues code
>
> I expect Kalle to add this sometime during the upcoming merge window
> (which opens tomorrow, according to the PHB crystal ball:
> http://phb-crystal-ball.org/).
>
>> * airtime fairness for the ath9k
>
> Haven't submitted a new version of this since the other things went in.
> While the basic scheduler works well, there are still some things to
> work out before making a serious attempt at upstreaming it (most notably
> the interaction with the hardware QoS queues). Also, moving parts of the
> code into mac80211 would make it easier to re-use in other drivers. Not
> sure which parts, though.
>
>> * Codel "hack" for low rates
>
> This still needs to be solved, but the hack I posted previously was just
> that: A hack. I think a different approach is needed.
>
>> As for what's in lede.... ?
>
> LEDE has the previous version of the mac80211 fix and the ath9k patch to
> enable the TXQ.
>
> -Toke



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Make-wifi-fast] net-next is next

[Dave Taht]

OK, so the only thing I don't have a full grip on is what the
napi-for-ath10k change did.

On Sat, Oct 1, 2016 at 11:09 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> I'm a little vague on the pieces missing as yet. I think?, still out
>> of tree are:
>
> Don't see anything missing from the list that I have been working on. Of
> the things I have:
>
>> * Hooking up the ath9k to the intermediate queues code
>
> I expect Kalle to add this sometime during the upcoming merge window
> (which opens tomorrow, according to the PHB crystal ball:
> http://phb-crystal-ball.org/).
>
>> * airtime fairness for the ath9k
>
> Haven't submitted a new version of this since the other things went in.

Patches somewhere?

> While the basic scheduler works well, there are still some things to
> work out before making a serious attempt at upstreaming it (most notably
> the interaction with the hardware QoS queues).

I was more or less planning to ignore that. Nobody else bothers to
test flooding the hardware queues, why should we? :/ And the behavior
is better now, regardless. Can't we ignore it? :-P

>Also, moving parts of the
> code into mac80211 would make it easier to re-use in other drivers. Not
> sure which parts, though.

same here. Pursuing another chipset (like the mt76 or "c.h.i.p") might
lend insight. Sigh.

>> * Codel "hack" for low rates
>
> This still needs to be solved, but the hack I posted previously was just
> that: A hack. I think a different approach is needed.

I outlined a couple approaches in my previous (overlong, meandering)
blog entry ( http://blog.cerowrt.org/post/a_bit_about_bbr/ ) -
notably, "giving up" - and turning off codel at a decent sized
aggregate for the station, rather than at the global limit of one
packet.

And there were a few much easier things from layering on top of the
airtime fairness stuff that might make the impact of multiple stations
on codel less difficult - reducing the txop and reducing the
advertised txop - when highly contended.

Assembling enough pieces to tackle and test those approaches at slow,
middle, and fast rates... would be good, and hopefully I've got a grip
on which pieces, now, thx.

>
>> As for what's in lede.... ?
>
> LEDE has the previous version of the mac80211 fix and the ath9k patch to
> enable the TXQ.

That's lede, not lede-staging?

>
> -Toke



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Make-wifi-fast] net-next is next

[Dave Taht]

OK, so the only thing I don't have a full grip on is what the
napi-for-ath10k change did.

My plan next week (sometime) would be to reassemble the various pieces
for ubuntu,
for the x86 apu2 (ath9k, ath10k) and laptop (ath9k). If there's
something that can work on lede, groovy, the boxes I have readily
available are ubnt uap-lite and archer c7v2.

On Sat, Oct 1, 2016 at 11:09 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> I'm a little vague on the pieces missing as yet. I think?, still out
>> of tree are:
>
> Don't see anything missing from the list that I have been working on. Of
> the things I have:
>
>> * Hooking up the ath9k to the intermediate queues code
>
> I expect Kalle to add this sometime during the upcoming merge window
> (which opens tomorrow, according to the PHB crystal ball:
> http://phb-crystal-ball.org/).
>
>> * airtime fairness for the ath9k
>
> Haven't submitted a new version of this since the other things went in.

Patches somewhere?

> While the basic scheduler works well, there are still some things to
> work out before making a serious attempt at upstreaming it (most notably
> the interaction with the hardware QoS queues).

I was more or less planning to ignore that. Nobody else bothers to
test flooding the hardware queues, why should we? :/ And the behavior
is better now, regardless. Can't we ignore it? :-P

>Also, moving parts of the
> code into mac80211 would make it easier to re-use in other drivers. Not
> sure which parts, though.

same here. Pursuing another chipset (like the mt76 or "c.h.i.p") might
lend insight. Sigh.

>> * Codel "hack" for low rates
>
> This still needs to be solved, but the hack I posted previously was just
> that: A hack. I think a different approach is needed.

I outlined a couple approaches in my previous (overlong, meandering)
blog entry ( http://blog.cerowrt.org/post/a_bit_about_bbr/ ) -
notably, "giving up" - and turning off codel at a decent sized
aggregate for the station, rather than at the global limit of one
packet.

And there were a few much easier things from layering on top of the
airtime fairness stuff that might make the impact of multiple stations
on codel less difficult - reducing the txop and reducing the
advertised txop - when highly contended.

Assembling enough pieces to tackle and test those approaches at slow,
middle, and fast rates... would be good, and hopefully I've got a grip
on which pieces, now, thx.

>
>> As for what's in lede.... ?
>
> LEDE has the previous version of the mac80211 fix and the ath9k patch to
> enable the TXQ.

That's lede, not lede-staging?

>
> -Toke



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org