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

[Michal Kazior]

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/card
>>> interface nearly as tight as BQL is for the fq portion to behave
>>> sanely. I'd configure codel at a higher target and try to observe what
>>> is going on at the fq level til that got saner.
>>
>> That seems like two good goals.  So Emmanuel's BQL-like thing seems
>> like we'll need it soon.
>>
>> As for per-station airtime fairness, what's a good approximation of
>> that?  Perhaps round-robin between stations, one aggregate per turn,
>> where each aggregate has a maximum allowed latency?
>
> Strict round robin is a start, and simplest, yes. Sure.
>
> "Oldest station queues first" on a round (probably) has higher
> potential for maximizing txops, but requires more overhead. (shortest
> queue first would be bad). There's another algo based on last received
> packets from a station possibly worth fiddling with in the long run...
>
> as "maximum allowed latency" - well, to me that is eventually also a
> variable, based on the number of stations that have to be scheduled on
> that round. Trying to get away from 10 stations eating 5.7ms each +
> return traffic on a round would be nicer. If you want a constant, for
> now, aim for 2048us or 1TU.

The "one aggregate per turn" is a tricky.

I guess you can guarantee this sort of thing on ath9k/mt76.

This isn't the case for other drivers, e.g. ath10k has a flat tx
queue. You don't really know if the 40 frames you submitted will be
sent with 1, 2 or 3 aggregates. They might not be aggregated at all.

Best thing you can do is to estimate how much bytes can you fit into a
txop on target sta-tid/ac assuming you can get last/avg tx rate to
given station (should be doable on ath10k at least).

Moreover, for MU-MIMO you typically want to burst a few aggregates in
txop to make the sounding to pay off. And this is again tricky on flat
tx queue where you don't really know if target stations can do an
efficient MU transmission and worst case you'll end up with stacking
up 3 txops worth of data in queues.


Oh, and the unfortunate thing is ath10k does offloaded powersaving
which means some frames can clog up tx queues unnecessarily until next
TBTT. This is something that will need to be addressed as well in tx
scheduling. Not sure how yet.

A quick idea - perhaps we could unify ps_tx_buf with txqs and make use
of txqs internally regardless of wake_tx_queue implementation?


[...]
> [1] I've published a lot of stuff showing how damaging 802.11e's edca
> scheduling can be - I lean towards, at most, 2-3 aggregates being in
> the hardware, essentially disabling the VO queue on 802.11n (not sure
> on ac), in favor of VI, promoting or demoting an assembled aggregate
> from BE to BK or VI as needed at the last second before submitting it
> to the hardware, trying harder to only have one aggregate outstanding
> to one station at a time, etc.

Makes sense, but (again) tricky for drivers such as ath10k which have
a flat tx queue. Perhaps I could maintain a simulation of aggregates
or some sort of barriers and hope it's "good enough".


Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mwifiex: Empty Tx queue during suspend

[Amitkumar Karwar]

In cfg80211 suspend handler, stop the netif queue and
wait until all the Tx queues become empty. Start the
queues in resume handler.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 29b7f6e..21a40b8 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -20,6 +20,7 @@
 #include "cfg80211.h"
 #include "main.h"
 #include "11n.h"
+#include "wmm.h"
 
 static char *reg_alpha2;
 module_param(reg_alpha2, charp, 0);
@@ -3259,7 +3260,7 @@ static int mwifiex_cfg80211_suspend(struct wiphy *wiphy,
 {
struct mwifiex_adapter *adapter = mwifiex_cfg80211_get_adapter(wiphy);
struct mwifiex_ds_hs_cfg hs_cfg;
-   int i, ret = 0;
+   int i, ret = 0, retry_num = 10;
struct mwifiex_private *priv;
 
for (i = 0; i < adapter->priv_num; i++) {
@@ -3269,6 +3270,19 @@ static int mwifiex_cfg80211_suspend(struct wiphy *wiphy,
 
mwifiex_cancel_all_pending_cmd(adapter);
 
+   for (i = 0; i < adapter->priv_num; i++) {
+   priv = adapter->priv[i];
+   if (priv && priv->netdev)
+   mwifiex_stop_net_dev_queue(priv->netdev, adapter);
+   }
+
+   for (i = 0; i < retry_num; i++) {
+   if (!mwifiex_wmm_lists_empty(adapter))
+   usleep_range(1, 15000);
+   else
+   break;
+   }
+
if (!wowlan) {
mwifiex_dbg(adapter, ERROR,
"None of the WOWLAN triggers enabled\n");
@@ -3327,6 +3341,13 @@ static int mwifiex_cfg80211_resume(struct wiphy *wiphy)
struct cfg80211_wowlan_wakeup wakeup_report;
int i;
 
+   for (i = 0; i < adapter->priv_num; i++) {
+   priv = adapter->priv[i];
+   if (priv && priv->netdev)
+   mwifiex_wake_up_net_dev_queue(priv->netdev, adapter);
+   }
+
+   priv = mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_STA);
mwifiex_get_wakeup_reason(priv, HostCmd_ACT_GEN_GET, MWIFIEX_SYNC_CMD,
  _reason);
memset(_report, 0, sizeof(struct cfg80211_wowlan_wakeup));
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Michal Kazior]

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 !*backlog

Yep, makes sense.


> target will not be a constant in the long run.
>
> +   if (now - custom_codel_get_enqueue_time(skb) < p->target ||
> +   !*backlog) {
> +   /* went below - stay below for at least interval */
> +   vars->first_above_time = 0;
> +   return false;
> +   }
>
> *backlog < some_sane_value_for_an_aggregate_for_this_station
>
> Unlike regular codel *backlog should be a ptr to the queuesize for
> this station, not the total queue.
>
> regular codel, by using the shared backlog for all queues, is trying
> to get to a 1 packet depth for all queues, (see commit:
> 865ec5523dadbedefbc5710a68969f686a28d928 ), and store the flow in the
> network, not the queue...
>
> BUT in wifi's case you want to provide good service to all stations,
> which is filling up an aggregate
> for each... (and varying the "sane_value_for_the_aggregate" to suit
> per sta service time requirements in a given round of all stations).

This is tricky. Drivers that use minstrel can probably do the estimate
rather easily.

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

I'll try looking more into this. Any hints/suggestion welcome.


>
> ...
>
> +   fq->flows_cnt = 4096;
>
> 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-station. If you have 10 stations you still have 4096 flows
(actually 4096 + 16*10, because each tid - and there are 16 - has it's
own fallback flow in case of hash collision on the global flowmap to
maintain per-sta-tid queuing).

With that in mind do you still think 1024 is enough?


> 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 "near perfect" fq,
> which, at the cost of more cpu overhead, could cut the number of
> queues down by a lot, also. Eric did "perfect" fq with sch_fq...

Out of curiosity - do you have any numbers to compare against
fq_codel? Like hash collision probability vs number of active flows?


> (btw: another way to test how codel is working is to set flows_cnt to
> 1. I will probably end up doing that at some point)
>
> +   fq->perturbation = prandom_u32();
> +   fq->quantum = 300;
>
> quantum 300 is a good compromise to maximize delivery of small packets
> from different flows. Probably the right thing on a station.
>
> It also has cpu overhead. Quantum=1514 is more of the right thing on an AP.
>
> (but to wax philosophical, per packet fairness rather than byte
> fairness probably spreads errors across more flows in a wifi aggregate
> than byte fairness, thus 300 remains a decent compromise if you can
> spare the cpu)
>
> ...
>
> where would be a suitable place to make (count, ecn_marks, drops)
> visible in this subsystem?

I was thinking of using debugfs for starters and then, once things
settle down, move to nl80211. Maybe we could re-use some enums like
TCA_FQ_CODEL_TARGET? Not sure if that's the best idea though. We might
need extra knobs to control and/or have in mind we might want to
replace the queuing algorithm at some point in the future as well
(which will need a different set of knobs).


>
> ...
>
> Is this "per station" or per station, per 802.11e queue?

What do you have in mind by "this"?



Michał

>
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>
>
> On Fri, Feb 26, 2016 at 5:09 AM, 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
>> can't be simply fought with qdiscs for wireless
>> drivers. 11ac with MU-MIMO makes the problem
>> worse because the bandwidth-delay product 

per sta queuing - the ath9k statistics

[Dave Taht]

I have put together some of the patches for fq_codel and per-station
queuing inside the mac80211 portion of the stack flying around on
linux-wireless, to no real visible effect as yet.

Mostly testing uploads at the moment, from an x86 based client. It's
not clear if I have the code path enabled, either, nor how to check,
from userspace. (?) Topology is

x86 <-wifi-> wndr3800 <-ethernet-> pi

Latency is still poor, throughput is down slightly. I will start
printk-ing tomorrow.

I do have a few puzzling things

A) re the ath9k statistics

At the client (ubuntu x86, 4.5-rc7 + patches, Atheros AR5418 Wireless
Network Adapter [AR5008E ) I see

http://pastebin.com/rvKJnc1y

AMPDUs Queued HW:0  0 0 0
AMPDUs Queued SW:0  0 0 0
AMPDUs Completed:  1098389   7050 14967 0

At the AP (cerowrt 3.10.50) I see

http://pastebin.com/RTt7MNT6

AMPDUs Queued SW:  3009455 364214557331 0
AMPDUs Completed:  2961055 363353556982 0
AMPDUs Retried: 115311   7833 21489 0

In both cases the TX-Pkts-all is close to the  AMPDUs completed figure.

B) In the regular packet captures I see no tcp losses. I can see in an
aircap wifi retrying for every lost packet.

C) I do not see any ECN marks (presumably would be generated by the
codel implementation.)

D) I do see things nicely "fq"'d on the captures but that might be by
cerowrt rather than the ieee mac

E) tc qdisc show dev wlp2s0 shows the tc layer qdisc disabled

qdisc noqueue 0: root refcnt 2

which does imply that at least part of the new codepath is working,
but there are no stats out of that side yet...

Ah, well, at least the patchset compiled and didn't crash the box.

--
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] staging: wilc1000: use mutex instead of semaphore sem_cfg_values

[Chaehyun Lim]

This patch replaces struct semaphore sem_cfg_values with struct mutex
cfg_values_lock. It is better to use mutex than semaphore.

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 10 +-
 drivers/staging/wilc1000/host_interface.h |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 854b674..0a922c7 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -443,7 +443,7 @@ static s32 handle_cfg_param(struct wilc_vif *vif,
struct host_if_drv *hif_drv = vif->hif_drv;
int i = 0;
 
-   down(_drv->sem_cfg_values);
+   mutex_lock(_drv->cfg_values_lock);
 
if (cfg_param_attr->flag & BSS_TYPE) {
if (cfg_param_attr->bss_type < 6) {
@@ -725,7 +725,7 @@ static s32 handle_cfg_param(struct wilc_vif *vif,
netdev_err(vif->ndev, "Error in setting CFG params\n");
 
 ERRORHANDLER:
-   up(_drv->sem_cfg_values);
+   mutex_unlock(_drv->cfg_values_lock);
return result;
 }
 
@@ -3434,8 +3434,8 @@ int wilc_init(struct net_device *dev, struct host_if_drv 
**hif_drv_handler)
setup_timer(_drv->connect_timer, TimerCB_Connect, 0);
setup_timer(_drv->remain_on_ch_timer, ListenTimerCB, 0);
 
-   sema_init(_drv->sem_cfg_values, 1);
-   down(_drv->sem_cfg_values);
+   mutex_init(_drv->cfg_values_lock);
+   mutex_lock(_drv->cfg_values_lock);
 
hif_drv->hif_state = HOST_IF_IDLE;
hif_drv->cfg_values.site_survey_enabled = SITE_SURVEY_OFF;
@@ -3446,7 +3446,7 @@ int wilc_init(struct net_device *dev, struct host_if_drv 
**hif_drv_handler)
 
hif_drv->p2p_timeout = 0;
 
-   up(_drv->sem_cfg_values);
+   mutex_unlock(_drv->cfg_values_lock);
 
clients_count++;
 
diff --git a/drivers/staging/wilc1000/host_interface.h 
b/drivers/staging/wilc1000/host_interface.h
index 795c18c..01f3222 100644
--- a/drivers/staging/wilc1000/host_interface.h
+++ b/drivers/staging/wilc1000/host_interface.h
@@ -274,7 +274,7 @@ struct host_if_drv {
u8 assoc_bssid[ETH_ALEN];
struct cfg_param_attr cfg_values;
 
-   struct semaphore sem_cfg_values;
+   struct mutex cfg_values_lock;
struct semaphore sem_test_key_block;
struct semaphore sem_test_disconn_block;
struct semaphore sem_get_rssi;
-- 
2.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ath6kl: ignore WMI_TXE_NOTIFY_EVENTID based on fw capability flags

[Steve deRosier]

Certain 6004 firmware releases redefine the WMI_TXE_NOTIFY_EVENTID event
number and sends the new event frequently. However it doesn't have the
tx-err-notify feature and thus this firmware capability flag isn't set on
the firmware package. By guarding the processing of this event by the same
method we guard the sending of the WMI_SET_TXE_NOTIFY_CMDID command, we
can ignore the spurious event that we don't know how to process.

Without this change we call cfg80211_cqm_txe_notify() with possibly bad
data.

Signed-off-by: Steve deRosier 
---
 drivers/net/wireless/ath/ath6kl/wmi.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c 
b/drivers/net/wireless/ath/ath6kl/wmi.c
index a5e1de7..0b3e9c0 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -1584,6 +1584,11 @@ static int ath6kl_wmi_txe_notify_event_rx(struct wmi 
*wmi, u8 *datap, int len,
if (len < sizeof(*ev))
return -EINVAL;
 
+   if (vif->nw_type != INFRA_NETWORK ||
+   !test_bit(ATH6KL_FW_CAPABILITY_TX_ERR_NOTIFY,
+ vif->ar->fw_capabilities))
+   return -EOPNOTSUPP;
+
if (vif->sme_state != SME_CONNECTED)
return -ENOTCONN;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] ti: wl1251: Convert wl1251_notice to wiphy_info/pr_info

[Joe Perches]

Use the more common logging mechanisms.

Convert to wiphy_info as these wl1251_notice uses were actually
emitted at KERN_INFO.

Signed-off-by: Joe Perches 
---
 drivers/net/wireless/ti/wl1251/main.c   | 4 ++--
 drivers/net/wireless/ti/wl1251/sdio.c   | 2 +-
 drivers/net/wireless/ti/wl1251/wl1251.h | 3 ---
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wl1251/main.c 
b/drivers/net/wireless/ti/wl1251/main.c
index a0576e7..593bed9 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -1469,7 +1469,7 @@ static int wl1251_register_hw(struct wl1251 *wl)
 
wl->mac80211_registered = true;
 
-   wl1251_notice("loaded");
+   wiphy_info(wl->hw->wiphy, "loaded\n");
 
return 0;
 }
@@ -1503,7 +1503,7 @@ int wl1251_init_ieee80211(struct wl1251 *wl)
goto out;
 
wl1251_debugfs_init(wl);
-   wl1251_notice("initialized");
+   wiphy_info(wl->hw->wiphy, "initialized\n");
 
ret = 0;
 
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c 
b/drivers/net/wireless/ti/wl1251/sdio.c
index f48e985..cc52a97 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -382,7 +382,7 @@ static int __init wl1251_sdio_init(void)
 static void __exit wl1251_sdio_exit(void)
 {
sdio_unregister_driver(_sdio_driver);
-   wl1251_notice("unloaded");
+   pr_info("unloaded\n");
 }
 
 module_init(wl1251_sdio_init);
diff --git a/drivers/net/wireless/ti/wl1251/wl1251.h 
b/drivers/net/wireless/ti/wl1251/wl1251.h
index 5d520d2..62a40cc 100644
--- a/drivers/net/wireless/ti/wl1251/wl1251.h
+++ b/drivers/net/wireless/ti/wl1251/wl1251.h
@@ -54,9 +54,6 @@ enum {
 
 #define DEBUG_DUMP_LIMIT 1024
 
-#define wl1251_notice(fmt, arg...) \
-   printk(KERN_INFO DRIVER_PREFIX fmt "\n", ##arg)
-
 #define wl1251_info(fmt, arg...) \
printk(KERN_DEBUG DRIVER_PREFIX fmt "\n", ##arg)
 
-- 
2.6.3.368.gf34be46

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] ti: wl1251: Convert wl1251_info to wl1251_debug

[Joe Perches]

These logging messages are always emitted at KERN_DEBUG.

Add a DEBUG_ALWAYS enum to the debug type enum and convert the
macro and uses from wl1251_info( to wl1251_debug(DEBUG_ALWAYS,

Miscellanea:

o Remove the now unused wl1251_info macro

Signed-off-by: Joe Perches 
---
 drivers/net/wireless/ti/wl1251/init.c   | 10 +-
 drivers/net/wireless/ti/wl1251/main.c   |  4 ++--
 drivers/net/wireless/ti/wl1251/sdio.c   |  4 ++--
 drivers/net/wireless/ti/wl1251/wl1251.h |  6 ++
 4 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/ti/wl1251/init.c 
b/drivers/net/wireless/ti/wl1251/init.c
index 796ccf4..29a990d 100644
--- a/drivers/net/wireless/ti/wl1251/init.c
+++ b/drivers/net/wireless/ti/wl1251/init.c
@@ -411,11 +411,11 @@ int wl1251_hw_init(struct wl1251 *wl)
goto out_free_data_path;
 
wl_mem_map = wl->target_mem_map;
-   wl1251_info("%d tx blocks at 0x%x, %d rx blocks at 0x%x",
-   wl_mem_map->num_tx_mem_blocks,
-   wl->data_path->tx_control_addr,
-   wl_mem_map->num_rx_mem_blocks,
-   wl->data_path->rx_control_addr);
+   wl1251_debug(DEBUG_ALWAYS, "%d tx blocks at 0x%x, %d rx blocks at 0x%x",
+wl_mem_map->num_tx_mem_blocks,
+wl->data_path->tx_control_addr,
+wl_mem_map->num_rx_mem_blocks,
+wl->data_path->rx_control_addr);
 
return 0;
 
diff --git a/drivers/net/wireless/ti/wl1251/main.c 
b/drivers/net/wireless/ti/wl1251/main.c
index 593bed9..32b8c98 100644
--- a/drivers/net/wireless/ti/wl1251/main.c
+++ b/drivers/net/wireless/ti/wl1251/main.c
@@ -423,7 +423,7 @@ static int wl1251_op_start(struct ieee80211_hw *hw)
 
wl->state = WL1251_STATE_ON;
 
-   wl1251_info("firmware booted (%s)", wl->fw_ver);
+   wl1251_debug(DEBUG_ALWAYS, "firmware booted (%s)", wl->fw_ver);
 
/* update hw/fw version info in wiphy struct */
wiphy->hw_version = wl->chip_id;
@@ -442,7 +442,7 @@ static void wl1251_op_stop(struct ieee80211_hw *hw)
 {
struct wl1251 *wl = hw->priv;
 
-   wl1251_info("down");
+   wl1251_debug(DEBUG_ALWAYS, "down");
 
wl1251_debug(DEBUG_MAC80211, "mac80211 stop");
 
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c 
b/drivers/net/wireless/ti/wl1251/sdio.c
index cc52a97..d2fb7d1 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -290,12 +290,12 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl1251_sdio_ops.enable_irq = wl1251_enable_line_irq;
wl1251_sdio_ops.disable_irq = wl1251_disable_line_irq;
 
-   wl1251_info("using dedicated interrupt line");
+   wl1251_debug(DEBUG_ALWAYS, "using dedicated interrupt line");
} else {
wl1251_sdio_ops.enable_irq = wl1251_sdio_enable_irq;
wl1251_sdio_ops.disable_irq = wl1251_sdio_disable_irq;
 
-   wl1251_info("using SDIO interrupt");
+   wl1251_debug(DEBUG_ALWAYS, "using SDIO interrupt");
}
 
ret = wl1251_init_ieee80211(wl);
diff --git a/drivers/net/wireless/ti/wl1251/wl1251.h 
b/drivers/net/wireless/ti/wl1251/wl1251.h
index 62a40cc..705573f 100644
--- a/drivers/net/wireless/ti/wl1251/wl1251.h
+++ b/drivers/net/wireless/ti/wl1251/wl1251.h
@@ -47,6 +47,7 @@ enum {
DEBUG_MAC80211  = BIT(11),
DEBUG_CMD   = BIT(12),
DEBUG_ACX   = BIT(13),
+   DEBUG_ALWAYS= BIT(31),
DEBUG_ALL   = ~0,
 };
 
@@ -54,12 +55,9 @@ enum {
 
 #define DEBUG_DUMP_LIMIT 1024
 
-#define wl1251_info(fmt, arg...) \
-   printk(KERN_DEBUG DRIVER_PREFIX fmt "\n", ##arg)
-
 #define wl1251_debug(level, fmt, arg...) \
do { \
-   if (level & DEBUG_LEVEL) \
+   if (level == DEBUG_ALWAYS || (level & DEBUG_LEVEL)) \
printk(KERN_DEBUG DRIVER_PREFIX fmt "\n", ##arg); \
} while (0)
 
-- 
2.6.3.368.gf34be46

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/5] wireless: ti: Convert specialized logging macros to kernel style

[Joe Perches]

Using the normal kernel logging mechanisms makes this code
a bit more like other wireless drivers.

Joe Perches (5):
  ti: Convert wl1271_ logging macros to dev_ or pr_
  ti: wl1251: Convert wl1251_error to wiphy_err/pr_err
  ti: wl1251: Convert wl1251_warning to wiphy_warn
  ti: wl1251: Convert wl1251_notice to wiphy_info/pr_info
  ti: wl1251: Convert wl1251_info to wl1251_debug

 drivers/net/wireless/ti/wl1251/acx.c  |  97 +++-
 drivers/net/wireless/ti/wl1251/boot.c |  18 +--
 drivers/net/wireless/ti/wl1251/cmd.c  |  52 ---
 drivers/net/wireless/ti/wl1251/event.c|   2 +-
 drivers/net/wireless/ti/wl1251/init.c |  27 ++--
 drivers/net/wireless/ti/wl1251/io.c   |   3 +-
 drivers/net/wireless/ti/wl1251/main.c |  75 +
 drivers/net/wireless/ti/wl1251/ps.c   |   2 +-
 drivers/net/wireless/ti/wl1251/rx.c   |   6 +-
 drivers/net/wireless/ti/wl1251/sdio.c |  25 +--
 drivers/net/wireless/ti/wl1251/spi.c  |  19 +--
 drivers/net/wireless/ti/wl1251/tx.c   |   9 +-
 drivers/net/wireless/ti/wl1251/wl1251.h   |  15 +-
 drivers/net/wireless/ti/wl12xx/acx.c  |   2 +-
 drivers/net/wireless/ti/wl12xx/cmd.c  |  20 +--
 drivers/net/wireless/ti/wl12xx/main.c |  34 ++--
 drivers/net/wireless/ti/wl12xx/scan.c |  24 +--
 drivers/net/wireless/ti/wl18xx/acx.c  |  25 +--
 drivers/net/wireless/ti/wl18xx/cmd.c  |  20 +--
 drivers/net/wireless/ti/wl18xx/debugfs.c  |   2 +-
 drivers/net/wireless/ti/wl18xx/event.c|   8 +-
 drivers/net/wireless/ti/wl18xx/main.c |  50 +++---
 drivers/net/wireless/ti/wl18xx/scan.c |  16 +-
 drivers/net/wireless/ti/wl18xx/tx.c   |   8 +-
 drivers/net/wireless/ti/wlcore/acx.c  | 132 
 drivers/net/wireless/ti/wlcore/boot.c |  45 +++---
 drivers/net/wireless/ti/wlcore/cmd.c  | 103 +++--
 drivers/net/wireless/ti/wlcore/debug.h|  14 +-
 drivers/net/wireless/ti/wlcore/debugfs.c  |  54 +++
 drivers/net/wireless/ti/wlcore/event.c|  14 +-
 drivers/net/wireless/ti/wlcore/main.c | 248 --
 drivers/net/wireless/ti/wlcore/ps.c   |  15 +-
 drivers/net/wireless/ti/wlcore/rx.c   |  26 ++--
 drivers/net/wireless/ti/wlcore/scan.c |   4 +-
 drivers/net/wireless/ti/wlcore/sysfs.c|   8 +-
 drivers/net/wireless/ti/wlcore/testmode.c |  14 +-
 drivers/net/wireless/ti/wlcore/tx.c   |  14 +-
 drivers/net/wireless/ti/wlcore/wlcore_i.h |   3 -
 38 files changed, 653 insertions(+), 600 deletions(-)

-- 
2.6.3.368.gf34be46

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dave Taht]

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.

+   if (now - custom_codel_get_enqueue_time(skb) < p->target ||
+   !*backlog) {
+   /* went below - stay below for at least interval */
+   vars->first_above_time = 0;
+   return false;
+   }


*backlog < some_sane_value_for_an_aggregate_for_this_station

Unlike regular codel *backlog should be a ptr to the queuesize for
this station, not the total queue.

regular codel, by using the shared backlog for all queues, is trying
to get to a 1 packet depth for all queues, (see commit:
865ec5523dadbedefbc5710a68969f686a28d928 ), and store the flow in the
network, not the queue...

BUT in wifi's case you want to provide good service to all stations,
which is filling up an aggregate
for each... (and varying the "sane_value_for_the_aggregate" to suit
per sta service time requirements in a given round of all stations).

...

+   fq->flows_cnt = 4096;

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.

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 "near perfect" fq,
which, at the cost of more cpu overhead, could cut the number of
queues down by a lot, also. Eric did "perfect" fq with sch_fq...

(btw: another way to test how codel is working is to set flows_cnt to
1. I will probably end up doing that at some point)

+   fq->perturbation = prandom_u32();
+   fq->quantum = 300;

quantum 300 is a good compromise to maximize delivery of small packets
from different flows. Probably the right thing on a station.

It also has cpu overhead. Quantum=1514 is more of the right thing on an AP.

(but to wax philosophical, per packet fairness rather than byte
fairness probably spreads errors across more flows in a wifi aggregate
than byte fairness, thus 300 remains a decent compromise if you can
spare the cpu)

...

where would be a suitable place to make (count, ecn_marks, drops)
visible in this subsystem?

...

Is this "per station" or per station, per 802.11e queue?

Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Fri, Feb 26, 2016 at 5:09 AM, 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
> can't be simply fought with qdiscs for wireless
> drivers. 11ac with MU-MIMO makes the problem
> worse because the bandwidth-delay product becomes
> even greater.
>
> This bases on codel5 and sch_fq_codel.c. It may
> not be the Right Thing yet but it should at least
> provide a framework for more improvements.
>
> I guess dropping rate could factor in per-station
> rate control info but I don't know how this should
> exactly be done. HW rate control drivers would
> need extra work to take advantage of this.
>
> This obviously works only with drivers that use
> wake_tx_queue op.
>
> Note: This uses IFF_NO_QUEUE to get rid of qdiscs
> for wireless drivers that use mac80211 and
> implement wake_tx_queue op.
>
> Moreover the current txq_limit and latency setting
> might need tweaking. Either from userspace or be
> dynamically scaled with regard to, e.g. number of
> associated stations.
>
> FWIW This already works nicely with ath10k's (not
> yey merged) pull-push congestion control for
> MU-MIMO as far as throughput is concerned.
>
> Evaluating latency improvements is a little tricky
> at this point if a driver is using more queue
> layering and/or its firmware controls tx
> scheduling - hence I don't have any solid data on
> this. I'm open for suggestions though.
>
> It might also be a good idea to do the following
> in the future:
>
>  - make generic tx scheduling which does some RR
>over per-sta-tid queues and dequeues bursts of
>packets to form a PPDU to fit into designated
>txop timeframe and bytelimit
>
>This could in theory be shared and used by
>ath9k and (future) mt76.
>
>Moreover tx scheduling could factor in rate
>control info and keep per-station number of
>queued packets at a sufficient low threshold to
>avoid queue buildup for slow stations. Emmanuel
>already did similar experiment for iwlwifi's
>station mode and got promising results.
>
>  - make 

Re: About adding support for MT76x2U to Linux kernel

[Felix Fietkau]

On 2016-03-07 13:41, Johannes Stezenbach wrote:
> On Mon, Mar 07, 2016 at 12:51:43PM +0100, Felix Fietkau wrote:
>> On 2016-03-07 12:14, Johannes Stezenbach wrote:
>> > FWIW, the mt7610u vendor driver
>> > doesn't support AP mode, while the mt7612u vendor driver does,
>> > but I didn't understand how their timing of sending buffered
>> > frames works.
>> Where can I find the most recent version of that vendor driver?
>> I can take a quick look at it.
> 
> http://www.mediatek.com/en/downloads1/downloads/
> or more specifically
> http://www.mediatek.com/en/downloads1/downloads/mt7612u/
I checked, they simply use a software timer for it and stuff buffered
multicast packets into the BE queue. I don't think the hardware offers
any better way of doing this...

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [01/21] brcmfmac: change function name forbrcmf_cfg80211_wait_vif_event_timeout()

[Arend Van Spriel]

On Mon, Mar 7, 2016 at 1:49 PM, Kalle Valo  wrote:
> Kalle Valo  writes:
>
>> 1 patches skipped:
>>
>> [17/21] brcmfmac: fix sdio sg table alloc crash
>>
>> There was a conflict so please rebase that patch:
>>
>> Applying: brcmfmac: fix sdio sg table alloc crash
>> fatal: sha1 information is lacking or useless 
>> (drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c).
>> Repository lacks necessary blobs to fall back on 3-way merge.
>> Cannot fall back to three-way merge.
>> Patch failed at 0001 brcmfmac: fix sdio sg table alloc crash
>
> Ah, I noticed only now your comment that this patch is in
> wireless-drivers already. So no actions needed.
>
> But in the future please don't submit the same patch twice, otherwise I
> accidentally commit it twice which is bad. Instead document the
> dependency and we can sort it out.

Yeah. We already discussed this earlier [1]. Has been noted.

Thanks,
Arend

[1] http://article.gmane.org/gmane.linux.kernel.wireless.general/148691

> --
> Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull-request: wireless-drivers 2016-03-04

[David Miller]

From: Kalle Valo 
Date: Fri, 04 Mar 2016 18:26:38 +0200

> three more fixes I would like to get to 4.5 still. It's getting late but
> I think these are still justified and these have been in linux-next
> almost a week. But if you think otherwise please let me know and I'll
> pull these to wireless-drivers-next instead.

Pulled, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V11 2/2] brcmfmac: add support for nl80211 BSS_SELECT feature

[Arend Van Spriel]

On Mon, Mar 7, 2016 at 1:52 PM, Kalle Valo  wrote:
> Arend van Spriel  writes:
>
>> Announce support for nl80211 feature BSS_SELECT and process
>> BSS selection behaviour provided in .connect() callback.
>>
>> Reviewed-by: Hante Meuleman 
>> Reviewed-by: Franky (Zhenhui) Lin 
>> Reviewed-by: Pieter-Paul Giesberts 
>> Reviewed-by: Lei Zhang 
>> Signed-off-by: Arend van Spriel 
>
> Depends on:
>
> 0a87cadbb54e nl80211: add feature for BSS selection support
>
> Is in mac80211-next currently.

Yes.

$ git log --oneline mac80211-next/master -1 -- include/uapi/linux/nl80211.h
0a87cad nl80211: add feature for BSS selection support

Regards,
Arend

> --
> Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dave Taht]

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... this week. it's very exciting
>> watching all this activity...
>>
>> but I confess that I've totally lost track of what set of trees and
>> patchwork I should try to pull from. wireless-drivers-next? ath10k?
>> wireless-next? net-next? toke and I have a ton of x86 platforms
>> available to test on
>>
>> Avery - which patches did you use??? on top of what?
>
> The patch series I'm currently using can be found here:
>
>   git fetch https://gfiber.googlesource.com/vendor/opensource/backports
> ath9k_txq+fq_codel

No common commits, but ok, thx for a buildable-looking tree.

d@dancer:~/git/linux$ git clone -b ath9k_txq+fq_codel --reference
net-next https://gfiber.googlesource.com/vendor/opensource/backports
Cloning into 'backports'...
warning: no common commits
remote: Sending approximately 30.48 MiB ...
remote: Counting objects: 4758, done
remote: Finding sources: 100% (5/5)
remote: Total 19312 (delta 12999), reused 19308 (delta 12999)
Receiving objects: 100% (19312/19312), 30.48 MiB | 6.23 MiB/s, done.
Resolving deltas: 100% (12999/12999), done.


>
> That's again backports-20160122, which comes from linux-next as of
> 20160122.  You can either build backports against whatever kernel
> you're using (probably easiest) or try to use that version of
> linux-next, or rebase the patches onto your favourite kernel.
>
>> In terms of "smoothing" codel...
>>
>> I emphatically do not think codel in it's current form is "ready" for
>> wireless, at the very least the target should not be much lower than
>> 20ms in your 2 station tests.  There is another bit in codel where the
>> algo "turns off" with only a single MTU's worth of packets
>> outstanding, which could get bumped to the ideal size of the
>> aggregate. "ideal" kind of being a variable based on a ton of other
>> factors...
>
> Yeah, I figured that sort of thing would come up.  I'm feeling forward
> progress just by finally seeing the buggy oscillations finally happen,
> though. :)

It's *very* exciting to see y'all break things in a measurable, yet
positive direction.

>
>> the underlying code needs to be striving successfully for per-station
>> airtime fairness for this to work at all, and the driver/card
>> interface nearly as tight as BQL is for the fq portion to behave
>> sanely. I'd configure codel at a higher target and try to observe what
>> is going on at the fq level til that got saner.
>
> That seems like two good goals.  So Emmanuel's BQL-like thing seems
> like we'll need it soon.
>
> As for per-station airtime fairness, what's a good approximation of
> that?  Perhaps round-robin between stations, one aggregate per turn,
> where each aggregate has a maximum allowed latency?

Strict round robin is a start, and simplest, yes. Sure.

"Oldest station queues first" on a round (probably) has higher
potential for maximizing txops, but requires more overhead. (shortest
queue first would be bad). There's another algo based on last received
packets from a station possibly worth fiddling with in the long run...

as "maximum allowed latency" - well, to me that is eventually also a
variable, based on the number of stations that have to be scheduled on
that round. Trying to get away from 10 stations eating 5.7ms each +
return traffic on a round would be nicer. If you want a constant, for
now, aim for 2048us or 1TU.

> I don't know how
> the current code works, but it's probably almost like that, as long as
> we only put one aggregate's worth of stuff into each hwq, which I
> guess is what the BQL-like thing will do.

I would avoid trying to think about or using 802.11e's 4 queues at the
moment[1]. We also have fallout from mu-mimo to deal with, eventually,
also, but gang scheduling starts to fall out naturally from these
structures and methods...

>
> So if I understand correctly, what we need is, in the following order:
> 1) Disable fq_codel for now, and get BQL-like thing working in ath9k
> (and ensure we're getting airtime fairness even without fq_codel);
> 2) Re-enable fq_codel and increase fq_codel's target up to 20ms for now;
> 3) Tweak fq_codel's "turn off" size to be larger (how important is this?)
>
> Is that right?

Sounds good. I have not reviewed the codel5 based implementation, it
may not even have idea "#3" in it at the moment at all.  The relevant
line in  codel.h is in codel_should_drop

" if (codel_time_before(vars->ldelay, params->target) ||
sch->qstats.backlog <= stats->maxpacket) {"

where instead of maxpacket you might use "some currently good looking
number for the a good aggregate size for this station". I sadly note
that in wifi you also have to worry about packets (42 max on n) AND

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

[Grumbach, Emmanuel]

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. it's very exciting
>> watching all this activity...
>>
>> but I confess that I've totally lost track of what set of trees and
>> patchwork I should try to pull from. wireless-drivers-next? ath10k?
>> wireless-next? net-next? toke and I have a ton of x86 platforms
>> available to test on
>>
>> Avery - which patches did you use??? on top of what?
>
> The patch series I'm currently using can be found here:
>
>git fetch https://gfiber.googlesource.com/vendor/opensource/backports
> ath9k_txq+fq_codel
>
> That's again backports-20160122, which comes from linux-next as of
> 20160122.  You can either build backports against whatever kernel
> you're using (probably easiest) or try to use that version of
> linux-next, or rebase the patches onto your favourite kernel.
>
>> In terms of "smoothing" codel...
>>
>> I emphatically do not think codel in it's current form is "ready" for
>> wireless, at the very least the target should not be much lower than
>> 20ms in your 2 station tests.  There is another bit in codel where the
>> algo "turns off" with only a single MTU's worth of packets
>> outstanding, which could get bumped to the ideal size of the
>> aggregate. "ideal" kind of being a variable based on a ton of other
>> factors...
>
> Yeah, I figured that sort of thing would come up.  I'm feeling forward
> progress just by finally seeing the buggy oscillations finally happen,
> though. :)
>
>> the underlying code needs to be striving successfully for per-station
>> airtime fairness for this to work at all, and the driver/card
>> interface nearly as tight as BQL is for the fq portion to behave
>> sanely. I'd configure codel at a higher target and try to observe what
>> is going on at the fq level til that got saner.
>
> That seems like two good goals.  So Emmanuel's BQL-like thing seems
> like we'll need it soon.

Well... I am going to do that for station only, and only for iwlwifi.
I haven't had a chance to work on that since then :( but I hope to get 
back to it. I also need to check what happens in multiple channels 
scenarios (in which there is inherent latency).
AP and stations have different challenges.

>
> As for per-station airtime fairness, what's a good approximation of
> that?  Perhaps round-robin between stations, one aggregate per turn,
> where each aggregate has a maximum allowed latency?  I don't know how
> the current code works, but it's probably almost like that, as long as
> we only put one aggregate's worth of stuff into each hwq, which I
> guess is what the BQL-like thing will do.
>
> So if I understand correctly, what we need is, in the following order:
> 1) Disable fq_codel for now, and get BQL-like thing working in ath9k
> (and ensure we're getting airtime fairness even without fq_codel);
> 2) Re-enable fq_codel and increase fq_codel's target up to 20ms for now;
> 3) Tweak fq_codel's "turn off" size to be larger (how important is this?)
>
> Is that right?
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Dave Taht]

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 trees and
patchwork I should try to pull from. wireless-drivers-next? ath10k?
wireless-next? net-next? toke and I have a ton of x86 platforms
available to test on

Avery - which patches did you use??? on top of what?

In terms of "smoothing" codel...

I emphatically do not think codel in it's current form is "ready" for
wireless, at the very least the target should not be much lower than
20ms in your 2 station tests.  There is another bit in codel where the
algo "turns off" with only a single MTU's worth of packets
outstanding, which could get bumped to the ideal size of the
aggregate. "ideal" kind of being a variable based on a ton of other
factors...

the underlying code needs to be striving successfully for per-station
airtime fairness for this to work at all, and the driver/card
interface nearly as tight as BQL is for the fq portion to behave
sanely. I'd configure codel at a higher target and try to observe what
is going on at the fq level til that got saner.

There are so many other variables and things left unaccounted for, as yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Avery Pennarun]

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
  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 the mt76 driver which uses them.)
>>>
>>> Patches for ath10k are under review since quite some time now (but are
>>> not merged yet). The latest re-spin is:
>>>
>>>   http://lists.infradead.org/pipermail/ath10k/2016-March/006923.html
>>
>> Hi all, on Friday I had a chance to experiment with some of these
>> patches, specifically Tim's ath9k patch (to use intermediate queues),
>> plus MIchal's patch to use fq_codel with the intermediate queues.  I
>> didn't attempt any fine tuning; I just slapped them together to see
>> what happens.  (I tried applying Michal's ath10k patches too, but got
>> stuck since they seem to be applied against the upstream v4.4 kernel
>> and didn't merge cleanly with the latest mac80211 branch.  Maybe I was
>> doing something wrong.)
>>
>> Test setup:
>>AP (ath9k) -> 2x2 strong signal -> STA1 (mwifiex)
>> -> attenuator (-40 dB) -> 1x1 weak signal  -> STA2 (mwifiex)
>>
>> STA2 generally gets modulation levels around MCS0-2 and STA1 usually
>> gets something like MCS12-15.
>>
>> With or without this patch, results with TCP iperf were fishy - I
>> think packet loss patterns were particularly bad and caused 2-second
>> TCP retry timeouts occasionally - so I removed TCP from the test and
>> switched the UDP iperf instead.
>>
>> I ran isoping 
>> (https://gfiber.googlesource.com/vendor/google/platform/+/master/cmds/isoping.c)
>> from the AP to both stations to measure two-way latency during all
>> tests.  (I used -r2 for two packets/sec in each direction in order not
>> to affect the test results too much.)
>>
>> Overall results:
>>
>> - Running one iperf at a time, I saw ~45 Mbps to STA1 and ~7 Mbps to STA2.
>>
>> - Running both iperfs at once, without the patches, latencies got
>> extremely high (~600ms sometimes) and results were closer to
>> byte-fairness than airtime-fairness (ie. ~7 Mbps each).
>>
>> - Running both iperfs at once, with the patches, latencies were still
>> high (usually high 2-digit, sometimes low 3-digit latencies) but we
>> got closer to airtime-fairness than byte-fairness (~17 Mbps and ~2
>> Mbps).
>>
>> - With only one iperf running, without the patches, latencies were
>> high to both stations.  With the patches, latency was
>> mid-double-digits to the non-iperf station (pretty good!) while being
>> low-mid triple-digits to the busy iperf station.  This suggests that
>> we are getting per-station queuing (yay!) but does make me question
>> whether the fq_ in fq_codel was working.
>
> Please change the 'if (flow->txqi)' check in ieee80211_txq_enqueue to:
> if (flow->txqi && flow->txqi != txqi)
> This should hopefully fix the fq_ part ;)

Oops, I saw your message about that earlier and totally forgot to
apply the change.  But maybe that was for the best, because it doesn't
seem to uniformly make things better.

*Without* your change, I observe that my iperf3 session to STA1 (high
speed) seems to complain about a lot of out-of-order packets.  *With*
your change, the out-of-order complaints seem to go away, which is
nice.  The throughput measurements look about the same both ways.

However, *without* your change, isoping latency to STA1 (low speed)
seems to be pretty stable in the ~100ms range (although it fluctuates
a bit).  *With* your change, STA2 latency fluctuates wildly as low as
1.x ms (yay!) but as high as 800ms (boo).  STA1 latency is fairly low
in both cases.

I have to admit, I haven't read any of this code in enough detail to
have a guess as to why this might be. But I did switch back and forth
between the two versions a few times to confirm that it seems to be
repeatable.

Just to compare, I went back to a version that contains only Tim's
patch (intermediate queues) but not fq_codel.  That one seems to have
much less variability in the isoping times (~50-100ms under load).
The best case isn't as good, but the worst case is much less bad.
This suggests to me that maybe codel's per-station drop rate is
oscillating (perhaps it needs to ramp less quickly?).  I wonder if the
competing codels between stations also confuse each other: as one
ramps down, maybe the other one would be encouraged to ramp up?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v1] mac80211: Add support for per station rx stats histogram

[Mohammed Shafi Shajakhan]

Hi Johannes and all,

kindly share your thoughts regarding the draft change
(I can share the test results as well and sample dump).

This is an implementation of Rx statistics (histogram
for each of the clients connected under mac80211 station
debugfs).

Attached is a sample dump, tested in Openwrt distribution

regards,
shafi


On Mon, Mar 07, 2016 at 09:53:29PM +0530, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Enable a provision in mac80211 'MAC80211_DEBUG_PER_STA_RX_STATS'
> to keep track and dump per station stats.
> 
> Dump rx pkts / bytes per {MCS, BW, NSS, GI} per station
> in histogram format. Rx stats provides a history
> of the receive stats of the stations connected to us.
> Information such as how consistently we received the packet
> in higher MCS index / Bandwidth is very useful to assess the
> performance of us(AP) and the connected clients
> 
> By default this feature is disabled though there is no impact
> in performance (based on our test results)
> 
> This change is based on the design of Yanbo Li and HT packet
> rate table fix by Anil
> 
> Signed-off-by: Mohammed Shafi Shajakhan 
> Signed-off-by: Anilkumar Kolli 
> ---
>  net/mac80211/Kconfig   |   12 +++
>  net/mac80211/debugfs_sta.c |  225 
> 
>  net/mac80211/debugfs_sta.h |5 +
>  net/mac80211/rx.c  |2 +
>  net/mac80211/sta_info.h|   23 +
>  5 files changed, 267 insertions(+)
> 
> diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
> index 3891cbd..89fb17c 100644
> --- a/net/mac80211/Kconfig
> +++ b/net/mac80211/Kconfig
> @@ -309,6 +309,18 @@ config MAC80211_DEBUG_COUNTERS
>  
> If unsure, say N.
>  
> +config MAC80211_DEBUG_PER_STA_RX_STATS
> + bool "Per Station Receive Stats Histogram"
> + depends on MAC80211_DEBUG_MENU
> + depends on MAC80211_DEBUGFS
> + ---help---
> +   Selecting this option causes mac80211 to keep track of
> +   per station received packets, classify them based
> +   on Bandwidth, Rate index (legacy, HT, VHT) and dump
> +   a histogram of the same
> +
> +   If unsure, say N.
> +
>  config MAC80211_STA_HASH_MAX_SIZE
>   int "Station hash table maximum size" if MAC80211_DEBUG_MENU
>   default 0
> diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
> index a39512f..ed095f3 100644
> --- a/net/mac80211/debugfs_sta.c
> +++ b/net/mac80211/debugfs_sta.c
> @@ -289,6 +289,130 @@ static ssize_t sta_ht_capa_read(struct file *file, char 
> __user *userbuf,
>  }
>  STA_OPS(ht_capa);
>  
> +static ssize_t sta_rx_stats_read(struct file *file, char __user *userbuf,
> +  size_t count, loff_t *ppos)
> +{
> +#ifdef CONFIG_MAC80211_DEBUG_PER_STA_RX_STATS
> +#define RX_STATS_HIST_FMT(n) \
> + do { \
> + if ((i + 1) % n == 0) \
> + len += scnprintf(buf + len, size - len, "\n\t\t"); \
> + } while (0)
> + int retval = 0, len = 0;
> + char *buf;
> + const int size = 3072;
> + struct sta_info *sta = file->private_data;
> + struct ieee80211_local *local = sta->local;
> + int i;
> + char *bw_str[IEEE80211_BW_NUM] = {"20", "40", "80", "160"};
> + char *nss_str[IEEE80211_NSS_NUM] = {"1x1", "2x2", "3x3", "4x4"};
> + char *gi_str[IEEE80211_GI_NUM] = {"LGI", "SGI"};
> + char *legacy_str[IEEE80211_LEGACY_RATE_NUM] = {"1", "2", "5.5",
> +"11", "6", "9",
> +"12", "18", "24",
> +"36", "48", "54"};
> + buf = kzalloc(size, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + len += scnprintf(buf + len, size - len, "VHT MCS packets: ");
> + for (i = 0; i < IEEE80211_VHT_MCS_NUM; i++) {
> + len += scnprintf(buf + len, size - len, "MCS %d: %llu, ",
> +  i, sta->rx_vht_pkt[i]);
> + RX_STATS_HIST_FMT(5);
> + }
> +
> + len += scnprintf(buf + len, size - len, "\nHT MCS packets: ");
> + for (i = 0; i < IEEE80211_HT_MCS_NUM; i++) {
> + len += scnprintf(buf + len, size - len, "MCS %d: %llu, ",
> +  i, sta->rx_ht_pkt[i]);
> + RX_STATS_HIST_FMT(5);
> + }
> +
> + len += scnprintf(buf + len, size - len, "\n\nBW packets: ");
> + for (i = 0; i < IEEE80211_BW_NUM; i++)
> + len += scnprintf(buf + len, size - len, "\t%sMhz: %llu",
> +  bw_str[i], sta->rx_bw_pkt[i]);
> +
> + len += scnprintf(buf + len, size - len, "\n\nNSS packets: ");
> + for (i = 0; i < IEEE80211_NSS_NUM; i++)
> + len += scnprintf(buf + len, size - len, "\t%s: %llu",
> +  nss_str[i], sta->rx_nss_pkt[i]);
> +
> + len += scnprintf(buf + len, size - 

[RFC] mac80211: Add support for per station rx stats histogram

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

Enable a provision in mac80211 'MAC80211_DEBUG_PER_STA_RX_STATS'
to keep track and dump per station stats.

Dump rx pkts / bytes per {MCS, BW, NSS, GI} per station
in histogram format. Rx stats provides a history
of the receive stats of the stations connected to us.
Information such as how consistently we received the packet
in higher MCS index / Bandwidth is very useful to assess the
performance of us(AP) and the connected clients

By default this feature is disabled though there is no impact
in performance (based on our test results)

This change is based on the design of Yanbo Li and HT packet
rate table fix by Anil

Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: Anilkumar Kolli 
---
 net/mac80211/Kconfig   |   12 +++
 net/mac80211/debugfs_sta.c |  231 
 net/mac80211/debugfs_sta.h |5 +
 net/mac80211/rx.c  |2 +
 net/mac80211/sta_info.h|   23 +
 5 files changed, 273 insertions(+)

diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 3891cbd..89fb17c 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -309,6 +309,18 @@ config MAC80211_DEBUG_COUNTERS
 
  If unsure, say N.
 
+config MAC80211_DEBUG_PER_STA_RX_STATS
+   bool "Per Station Receive Stats Histogram"
+   depends on MAC80211_DEBUG_MENU
+   depends on MAC80211_DEBUGFS
+   ---help---
+ Selecting this option causes mac80211 to keep track of
+ per station received packets, classify them based
+ on Bandwidth, Rate index (legacy, HT, VHT) and dump
+ a histogram of the same
+
+ If unsure, say N.
+
 config MAC80211_STA_HASH_MAX_SIZE
int "Station hash table maximum size" if MAC80211_DEBUG_MENU
default 0
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index a39512f..85c66ef 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -289,6 +289,136 @@ static ssize_t sta_ht_capa_read(struct file *file, char 
__user *userbuf,
 }
 STA_OPS(ht_capa);
 
+static ssize_t sta_rx_stats_read(struct file *file, char __user *userbuf,
+size_t count, loff_t *ppos)
+{
+#ifdef CONFIG_MAC80211_DEBUG_PER_STA_RX_STATS
+#define RX_STATS_HIST_FMT(n) \
+   do { \
+   if ((i + 1) % n == 0) \
+   len += scnprintf(buf + len, size - len, "\n\t\t"); \
+   } while (0)
+   int retval = 0, len = 0;
+   char *buf;
+   const int size = 3072;
+   struct sta_info *sta = file->private_data;
+   struct ieee80211_local *local = sta->local;
+   int i;
+   char *bw_str[IEEE80211_BW_NUM] = {"20", "40", "80", "160"};
+   char *nss_str[IEEE80211_NSS_NUM] = {"1x1", "2x2", "3x3", "4x4"};
+   char *gi_str[IEEE80211_GI_NUM] = {"LGI", "SGI"};
+   char *legacy_str[IEEE80211_LEGACY_RATE_NUM] = {"1", "2", "5.5",
+  "11", "6", "9",
+  "12", "18", "24",
+  "36", "48", "54"};
+   buf = kzalloc(size, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   len += scnprintf(buf + len, size - len, "VHT MCS packets: ");
+   for (i = 0; i < IEEE80211_VHT_MCS_NUM; i++) {
+   len += scnprintf(buf + len, size - len, "MCS %d: %llu, ",
+i, sta->rx_vht_pkt[i]);
+   RX_STATS_HIST_FMT(5);
+   }
+
+   len += scnprintf(buf + len, size - len, "\nHT MCS packets: ");
+   for (i = 0; i < IEEE80211_HT_MCS_NUM; i++) {
+   len += scnprintf(buf + len, size - len, "MCS %d: %llu, ",
+i, sta->rx_ht_pkt[i]);
+   RX_STATS_HIST_FMT(5);
+   }
+
+   len += scnprintf(buf + len, size - len, "\n\nBW packets: ");
+   for (i = 0; i < IEEE80211_BW_NUM; i++)
+   len += scnprintf(buf + len, size - len, "\t%sMhz: %llu",
+bw_str[i], sta->rx_bw_pkt[i]);
+
+   len += scnprintf(buf + len, size - len, "\n\nNSS packets: ");
+   for (i = 0; i < IEEE80211_NSS_NUM; i++)
+   len += scnprintf(buf + len, size - len, "\t%s: %llu",
+nss_str[i], sta->rx_nss_pkt[i]);
+
+   len += scnprintf(buf + len, size - len, "\n\nGI packets: ");
+   for (i = 0; i < IEEE80211_GI_NUM; i++)
+   len += scnprintf(buf + len, size - len, "\t%s: %llu",
+gi_str[i], sta->rx_gi_pkt[i]);
+
+   len += scnprintf(buf + len, size - len, "\n\nLegacy rate packets: ");
+   for (i = 0; i < IEEE80211_LEGACY_RATE_NUM; i++) {
+   len += scnprintf(buf + len, size - len, "\t%sMbps: %llu",
+legacy_str[i], sta->rx_legacy_pkt[i]);
+   

[RFC v1] mac80211: Add support for per station rx stats histogram

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

Enable a provision in mac80211 'MAC80211_DEBUG_PER_STA_RX_STATS'
to keep track and dump per station stats.

Dump rx pkts / bytes per {MCS, BW, NSS, GI} per station
in histogram format. Rx stats provides a history
of the receive stats of the stations connected to us.
Information such as how consistently we received the packet
in higher MCS index / Bandwidth is very useful to assess the
performance of us(AP) and the connected clients

By default this feature is disabled though there is no impact
in performance (based on our test results)

This change is based on the design of Yanbo Li and HT packet
rate table fix by Anil

Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: Anilkumar Kolli 
---
 net/mac80211/Kconfig   |   12 +++
 net/mac80211/debugfs_sta.c |  225 
 net/mac80211/debugfs_sta.h |5 +
 net/mac80211/rx.c  |2 +
 net/mac80211/sta_info.h|   23 +
 5 files changed, 267 insertions(+)

diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 3891cbd..89fb17c 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -309,6 +309,18 @@ config MAC80211_DEBUG_COUNTERS
 
  If unsure, say N.
 
+config MAC80211_DEBUG_PER_STA_RX_STATS
+   bool "Per Station Receive Stats Histogram"
+   depends on MAC80211_DEBUG_MENU
+   depends on MAC80211_DEBUGFS
+   ---help---
+ Selecting this option causes mac80211 to keep track of
+ per station received packets, classify them based
+ on Bandwidth, Rate index (legacy, HT, VHT) and dump
+ a histogram of the same
+
+ If unsure, say N.
+
 config MAC80211_STA_HASH_MAX_SIZE
int "Station hash table maximum size" if MAC80211_DEBUG_MENU
default 0
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index a39512f..ed095f3 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -289,6 +289,130 @@ static ssize_t sta_ht_capa_read(struct file *file, char 
__user *userbuf,
 }
 STA_OPS(ht_capa);
 
+static ssize_t sta_rx_stats_read(struct file *file, char __user *userbuf,
+size_t count, loff_t *ppos)
+{
+#ifdef CONFIG_MAC80211_DEBUG_PER_STA_RX_STATS
+#define RX_STATS_HIST_FMT(n) \
+   do { \
+   if ((i + 1) % n == 0) \
+   len += scnprintf(buf + len, size - len, "\n\t\t"); \
+   } while (0)
+   int retval = 0, len = 0;
+   char *buf;
+   const int size = 3072;
+   struct sta_info *sta = file->private_data;
+   struct ieee80211_local *local = sta->local;
+   int i;
+   char *bw_str[IEEE80211_BW_NUM] = {"20", "40", "80", "160"};
+   char *nss_str[IEEE80211_NSS_NUM] = {"1x1", "2x2", "3x3", "4x4"};
+   char *gi_str[IEEE80211_GI_NUM] = {"LGI", "SGI"};
+   char *legacy_str[IEEE80211_LEGACY_RATE_NUM] = {"1", "2", "5.5",
+  "11", "6", "9",
+  "12", "18", "24",
+  "36", "48", "54"};
+   buf = kzalloc(size, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   len += scnprintf(buf + len, size - len, "VHT MCS packets: ");
+   for (i = 0; i < IEEE80211_VHT_MCS_NUM; i++) {
+   len += scnprintf(buf + len, size - len, "MCS %d: %llu, ",
+i, sta->rx_vht_pkt[i]);
+   RX_STATS_HIST_FMT(5);
+   }
+
+   len += scnprintf(buf + len, size - len, "\nHT MCS packets: ");
+   for (i = 0; i < IEEE80211_HT_MCS_NUM; i++) {
+   len += scnprintf(buf + len, size - len, "MCS %d: %llu, ",
+i, sta->rx_ht_pkt[i]);
+   RX_STATS_HIST_FMT(5);
+   }
+
+   len += scnprintf(buf + len, size - len, "\n\nBW packets: ");
+   for (i = 0; i < IEEE80211_BW_NUM; i++)
+   len += scnprintf(buf + len, size - len, "\t%sMhz: %llu",
+bw_str[i], sta->rx_bw_pkt[i]);
+
+   len += scnprintf(buf + len, size - len, "\n\nNSS packets: ");
+   for (i = 0; i < IEEE80211_NSS_NUM; i++)
+   len += scnprintf(buf + len, size - len, "\t%s: %llu",
+nss_str[i], sta->rx_nss_pkt[i]);
+
+   len += scnprintf(buf + len, size - len, "\n\nGI packets: ");
+   for (i = 0; i < IEEE80211_GI_NUM; i++)
+   len += scnprintf(buf + len, size - len, "\t%s: %llu",
+gi_str[i], sta->rx_gi_pkt[i]);
+
+   len += scnprintf(buf + len, size - len, "\n\nLegacy rate packets: ");
+   for (i = 0; i < IEEE80211_LEGACY_RATE_NUM; i++) {
+   len += scnprintf(buf + len, size - len, "\t%sMbps: %llu",
+legacy_str[i], sta->rx_legacy_pkt[i]);
+   

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

[Felix Fietkau]

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
>>>  Michal mentioned he has patches for ath10k that are not yet released,
>>>  and I know Felix is finishing up the mt76 driver which uses them.)
>>
>> Patches for ath10k are under review since quite some time now (but are
>> not merged yet). The latest re-spin is:
>>
>>   http://lists.infradead.org/pipermail/ath10k/2016-March/006923.html
> 
> Hi all, on Friday I had a chance to experiment with some of these
> patches, specifically Tim's ath9k patch (to use intermediate queues),
> plus MIchal's patch to use fq_codel with the intermediate queues.  I
> didn't attempt any fine tuning; I just slapped them together to see
> what happens.  (I tried applying Michal's ath10k patches too, but got
> stuck since they seem to be applied against the upstream v4.4 kernel
> and didn't merge cleanly with the latest mac80211 branch.  Maybe I was
> doing something wrong.)
> 
> Test setup:
>AP (ath9k) -> 2x2 strong signal -> STA1 (mwifiex)
> -> attenuator (-40 dB) -> 1x1 weak signal  -> STA2 (mwifiex)
> 
> STA2 generally gets modulation levels around MCS0-2 and STA1 usually
> gets something like MCS12-15.
> 
> With or without this patch, results with TCP iperf were fishy - I
> think packet loss patterns were particularly bad and caused 2-second
> TCP retry timeouts occasionally - so I removed TCP from the test and
> switched the UDP iperf instead.
> 
> I ran isoping 
> (https://gfiber.googlesource.com/vendor/google/platform/+/master/cmds/isoping.c)
> from the AP to both stations to measure two-way latency during all
> tests.  (I used -r2 for two packets/sec in each direction in order not
> to affect the test results too much.)
> 
> Overall results:
> 
> - Running one iperf at a time, I saw ~45 Mbps to STA1 and ~7 Mbps to STA2.
> 
> - Running both iperfs at once, without the patches, latencies got
> extremely high (~600ms sometimes) and results were closer to
> byte-fairness than airtime-fairness (ie. ~7 Mbps each).
> 
> - Running both iperfs at once, with the patches, latencies were still
> high (usually high 2-digit, sometimes low 3-digit latencies) but we
> got closer to airtime-fairness than byte-fairness (~17 Mbps and ~2
> Mbps).
> 
> - With only one iperf running, without the patches, latencies were
> high to both stations.  With the patches, latency was
> mid-double-digits to the non-iperf station (pretty good!) while being
> low-mid triple-digits to the busy iperf station.  This suggests that
> we are getting per-station queuing (yay!) but does make me question
> whether the fq_ in fq_codel was working.
Please change the 'if (flow->txqi)' check in ieee80211_txq_enqueue to:
if (flow->txqi && flow->txqi != txqi)
This should hopefully fix the fq_ part ;)

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rtlwifi: Fix size of wireless mode variable

[Larry Finger]

On 03/07/2016 06:38 AM, Kalle Valo wrote:

Larry Finger  writes:


Smatch reports the following warning:

   CHECK   drivers/net/wireless/realtek/rtlwifi/rc.c
drivers/net/wireless/realtek/rtlwifi/rc.c:144 _rtl_rc_rate_set_series() warn: 
impossible condition '(wireless_mode == 256) => (0-255 == 256)'

This warning arises because commit acc6907b87a9 ("rtlwifi: Fix warning
from ieee80211_get_tx_rates() when using 5G") now checks the wireless
mode for WIRELESS_MODE_AC_ONLY (BIT(8)) in _rtl_rc_rate_set_series().
As a result, all quantities used to store the wireless mode must be u16.

This patch also reorders struct rtl_sta_info to save a little space.

Fixes: commit acc6907b87a9 ("rtlwifi: Fix warning from ieee80211_get_tx_rates() when 
using 5G")
Reported-by: Dan Williams 
Signed-off-by: Larry Finger 


I can't find commit acc6907b87a9 from any of my trees. And oddly enough
I can't either any commits with title "rtlwifi: Fix warning from
ieee80211_get_tx_rates() when using 5G". I can fix it before commiting
but what should I use?

Also the fixes line should not have the word "commit".


Kalle,

I do not know where I got that commit and title. The correct reference is commit 
d76d65fd2695 ("rtlwifi: fix broken VHT support").


If you would rather not fix this on commit, I can submit a new version.

Thanks,

Larry


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Avery Pennarun]

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 that are not yet released,
>>  and I know Felix is finishing up the mt76 driver which uses them.)
>
> Patches for ath10k are under review since quite some time now (but are
> not merged yet). The latest re-spin is:
>
>   http://lists.infradead.org/pipermail/ath10k/2016-March/006923.html

Hi all, on Friday I had a chance to experiment with some of these
patches, specifically Tim's ath9k patch (to use intermediate queues),
plus MIchal's patch to use fq_codel with the intermediate queues.  I
didn't attempt any fine tuning; I just slapped them together to see
what happens.  (I tried applying Michal's ath10k patches too, but got
stuck since they seem to be applied against the upstream v4.4 kernel
and didn't merge cleanly with the latest mac80211 branch.  Maybe I was
doing something wrong.)

Test setup:
   AP (ath9k) -> 2x2 strong signal -> STA1 (mwifiex)
-> attenuator (-40 dB) -> 1x1 weak signal  -> STA2 (mwifiex)

STA2 generally gets modulation levels around MCS0-2 and STA1 usually
gets something like MCS12-15.

With or without this patch, results with TCP iperf were fishy - I
think packet loss patterns were particularly bad and caused 2-second
TCP retry timeouts occasionally - so I removed TCP from the test and
switched the UDP iperf instead.

I ran isoping 
(https://gfiber.googlesource.com/vendor/google/platform/+/master/cmds/isoping.c)
from the AP to both stations to measure two-way latency during all
tests.  (I used -r2 for two packets/sec in each direction in order not
to affect the test results too much.)

Overall results:

- Running one iperf at a time, I saw ~45 Mbps to STA1 and ~7 Mbps to STA2.

- Running both iperfs at once, without the patches, latencies got
extremely high (~600ms sometimes) and results were closer to
byte-fairness than airtime-fairness (ie. ~7 Mbps each).

- Running both iperfs at once, with the patches, latencies were still
high (usually high 2-digit, sometimes low 3-digit latencies) but we
got closer to airtime-fairness than byte-fairness (~17 Mbps and ~2
Mbps).

- With only one iperf running, without the patches, latencies were
high to both stations.  With the patches, latency was
mid-double-digits to the non-iperf station (pretty good!) while being
low-mid triple-digits to the busy iperf station.  This suggests that
we are getting per-station queuing (yay!) but does make me question
whether the fq_ in fq_codel was working.

- More generally, the latencies were all still higher than expected.
I didn't investigate why this might be, but the obvious guess (which
Tim has agreed with) is that we need something BQL-like in addition to
the fq_codel layer.  The BQL-like thing is what Emmanuel's earlier
latency patch did with iwlwifi, with apparently good results.  If
someone wants to try making a similar patch for ath9k, I'd be happy to
help test it out.

Although things aren't yet nearly as good as I'd like to see them,
I'll note that Tim's and Michal's patches don't seem to make things
*worse*, at least in my setup, and do improve results in my test.  So
if they pass code review, it may make sense to apply them as one small
step forward to reducing wifi latency under load.

Have fun,

Avery
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: iwlwifi-next 2016-03-02

[Kalle Valo]

"Grumbach, Emmanuel"  writes:

> This is a pull request for 4.6. It is big because a lot of patches were
> waiting for code in mac80211-next which is now in net-next.
> As you figured, I need you to pull Johannes's 
> mac80211-next-for-davem-2016-02-26 before you pull this from me.
> Of course, you can just merge net-next. This is really up to you :)
> I also merged iwlwifi-fixes.git (twice even) to prevent conflicts upstream.
> In the tag, I mentioned which patches need mac80211-next since you asked for 
> it
> last time.
>
> My prevent_stupid_mistakes.sh script seems to be working fairly well now,
> in case you see an issue, let me know.
>
> Thanks!
>
>
> The following changes since commit 50ee738d7271fe825e4024cdfa5c5301a871e2c2:
>
>   rfkill: Add documentation about LED triggers (2016-02-24 09:13:12 +0100)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
> tags/iwlwifi-next-for-kalle-2016-03-02

Pulled, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [01/21] brcmfmac: change function name forbrcmf_cfg80211_wait_vif_event_timeout()

[Kalle Valo]

Kalle Valo  writes:

> 1 patches skipped:
>
> [17/21] brcmfmac: fix sdio sg table alloc crash
>
> There was a conflict so please rebase that patch:
>
> Applying: brcmfmac: fix sdio sg table alloc crash
> fatal: sha1 information is lacking or useless 
> (drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c).
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.
> Patch failed at 0001 brcmfmac: fix sdio sg table alloc crash

Ah, I noticed only now your comment that this patch is in
wireless-drivers already. So no actions needed.

But in the future please don't submit the same patch twice, otherwise I
accidentally commit it twice which is bad. Instead document the
dependency and we can sort it out.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] bcma: drop unneeded fields from bcma_pflash struct

[Kalle Valo]

Rafał Miłecki  writes:

> Most of info stored in this struct wasn't really used anywhere as we put
> all that data in platform data & resource as well.
>
> Signed-off-by: Rafał Miłecki 

Manually applied to wireless-drivers-next, thanks.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About adding support for MT76x2U to Linux kernel

[Johannes Stezenbach]

On Mon, Mar 07, 2016 at 12:51:43PM +0100, Felix Fietkau wrote:
> On 2016-03-07 12:14, Johannes Stezenbach wrote:
> > FWIW, the mt7610u vendor driver
> > doesn't support AP mode, while the mt7612u vendor driver does,
> > but I didn't understand how their timing of sending buffered
> > frames works.
> Where can I find the most recent version of that vendor driver?
> I can take a quick look at it.

http://www.mediatek.com/en/downloads1/downloads/
or more specifically
http://www.mediatek.com/en/downloads1/downloads/mt7612u/

> > Another concern is the handling of the TX status since there
> > is also no TX_STAT interrupt.  I remember from rt2800usb
> > it was always problematic to ensure no FIFO items were lost,
> > which is a problem for rt2800usb since it doesn't report
> > TX status before it got it from the hardware.
> > The mt7601u driver takes the approach to report IEEE80211_TX_STAT_ACK
> > immediately after urb completion, and send the real
> > status later from a delayed workqueue in mt7601u_tx_stat().
> > Could someone enlighten me if this approach is sane
> > wrt to minstrel rate control?
> When I started writing mt76 I did lots of experiments with trying to map
> TX_STAT_FIFO data to individual frames and pretty much gave up, because
> the status register was just too unreliable. Even in cases where it was
> reliable, mapping the status info to frames is expensive on slower
> embedded hardware, so I pretty much gave up on that approach and
> extended the rate control API to support submitting tx status
> information without the corresponding skb.
> 
> This turned out to work quite well, and I think it might be worth using
> to some extent even on drivers with proper skb tx status reporting,
> since it has better cache footprint and has to run less code.
> 
> I think the best approach is to try to map tx status info from
> TX_STAT_FIFO in cases where IEEE80211_TX_CTL_REQ_TX_STATUS is set, and
> just use ieee80211_tx_status_noskb for all other frames. I did something
> like that on my work-in-progress mt7603 code.

OK, I thought minstrels send some probe frames with high
rates to check if they go through and thus relies
on exact TX status for these? (IEEE80211_TX_CTL_RATE_CTRL_PROBE)

Thanks,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [V3] mt7601u: do not free dma_buf when ivp allocation fails

[Kalle Valo]

> From: Colin Ian King 
> 
> If the allocation of ivp fails the error handling attempts to
> free an uninitialized dma_buf; this data structure just contains
> garbage on the stack, so the freeing will cause issues when the
> urb, buf and dma fields are free'd. Fix this by not free'ing the
> dma_buf if the ivp allocation fails.
> 
> Signed-off-by: Colin Ian King 
> Reviewed-by: Julian Calaby 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/3] mwifiex: Fixed incorrect indentation issue

[Kalle Valo]

> This patch fixes the incorrect indentation of the case label.
> 
> Signed-off-by: Ujjal Roy 

Thanks, 3 patches applied to wireless-drivers-next.git:

32962d5b43b7 mwifiex: Fixed incorrect indentation issue
3a968d766a63 mwifiex: Removed extra spaces before commas
354a1947a025 mwifiex: Added missing spaces around brackets

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rt2x00: add new rt2800usb device Buffalo WLI-UC-G450

[Kalle Valo]

> Add USB ID 0411:01fd for Buffalo WLI-UC-G450 wireless adapter,
> RT chipset 3593
> 
> Signed-off-by: Anthony Wong 
> Cc: sta...@vger.kernel.org
> Acked-by: Stanislaw Gruszka 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/4] mwifiex: add delay when tdls confirm frame is queued

[Kalle Valo]

> From: Xinming Hu 
> 
> It is observed that driver may send the data packet to tdls peer
> before tdls peer receives tdls setup confirm frame.
> Similar race condition exists during tdls teardown procedure also.
> This patch adds 10 milliseconds delay to resolve the race.
> 
> Signed-off-by: Xinming Hu 
> Signed-off-by: Cathy Luo 
> Signed-off-by: Amitkumar Karwar 

Thanks, 4 patches applied to wireless-drivers-next.git:

de651ce3d750 mwifiex: add delay when tdls confirm frame is queued
a6139b6271f9 mwifiex: fix corner case association failure
8b7ef8b66eb9 mwifiex: add sdio multiport aggregation debug information
0cb52aac4d19 mwifiex: do not set multiport flag for tx/rx single packet

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [V2] rtlwifi: pass struct rtl_stats by reference as it is moreefficient

[Kalle Valo]

> From: Colin Ian King 
> 
> passing rtl_stats by value is inefficient; the structure is over 300
> bytes in size and generally just one field (packet_report_type)
> is being accessed, so the pass by value is a relatively large overhead.
> This change just affects just the rx_command_packet calls.
> 
> Signed-off-by: Colin Ian King 
> Acked-by: Larry Finger 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: at76c50x-usb: avoid double usb_put_dev() after downloading internalfirmware in at76_probe()

[Kalle Valo]

> There is no need in usb_put_dev() if at76_load_internal_fw() succeed.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex: Use to_delayed_work()

[Kalle Valo]

> Introduce the use of to_delayed_work() helper function instead of open
> coding it with container_of()
> 
> A simplified version of the Coccinelle semantic patch used to make
> this change is:
> 
> //
> @@
> expression a;
> symbol work;
> @@
> - container_of(a, struct delayed_work, work)
> + to_delayed_work(a)
> //
> 
> Signed-off-by: Amitoj Kaur Chawla 
> Reviewed-by: Julian Calaby 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [01/21] brcmfmac: change function name forbrcmf_cfg80211_wait_vif_event_timeout()

[Kalle Valo]

> Dropping the '_timeout' from the function name as the fact that a timeout
> value is passed makes it obvious a timeout is used. Also helps to keep code
> lines a bit shorter and easier to stick to 80 char boundary.
> 
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Pieter-Paul Giesberts 
> Signed-off-by: Arend van Spriel 

Thanks, 20 patches applied to wireless-drivers-next.git:

a9eb0c4b73e7 brcmfmac: change function name for 
brcmf_cfg80211_wait_vif_event_timeout()
d536733442d1 brcmfmac: Limit memory allocs to <64K
6ea09153b6cc brcmfmac: check for wowl support before enumerating feature flag
73345fd21298 brcmfmac: Configure country code using device specific settings
0aedbcaf6f18 brcmfmac: Add length checks on firmware events
52f22fb21764 brcmfmac: add neighbor discovery offload ip address table 
configuration
cd2bc19c61b2 brcmfmac: check return for ARP ip setting iovar
6ac27689b01e brcmfmac: use device memsize config from fw if defined
9300bf8610fd brcmfmac: use bar1 window size as provided by pci subsystem
bc86fdb9ac02 brcmfmac: add support for the PCIE 4366c0 chip
d457a44fd85c brcmfmac: remove pcie gen1 support
e9217b4b62a7 brcmfmac: increase timeout for tx eapol
d84d99e00777 brcmfmac: move module init and exit to common
5c22fb85102a brcmfmac: add wowl gtk rekeying offload support
8ea56be0869f brcmfmac: move platform data retrieval code to common
73ef9e640e94 brcmfmac: keep ARP and ND offload enabled during WOWL
4d7928959832 brcmfmac: switch to new platform data
af5b5e62f72e brcmfmac: merge platform data and module paramaters
219e0f747ad6 brcmfmac: integrate add_keyext in add_key
240d61a9ddeb brcmfmac: add 802.11w management frame protection support

1 patches skipped:

[17/21] brcmfmac: fix sdio sg table alloc crash

There was a conflict so please rebase that patch:

Applying: brcmfmac: fix sdio sg table alloc crash
fatal: sha1 information is lacking or useless 
(drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 brcmfmac: fix sdio sg table alloc crash

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: carl9170: import 1.9.9 firmware headers

[Kalle Valo]

> Import new headers from my firmware branch:
> 
> 
> Signed-off-by: Christian Lamparter 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/15] wil6210 patches

[Valo, Kalle]

Maya Erez  writes:

> Changes in V2:
> - Fixed oob_mode module parameter description
>
> This set of patches includes:
> - wil6210 bug fixes
> - P2P support
> - switch to generated wmi.h
> - replay attack detection
>
> Dedy Lansky (1):
>   wil6210: p2p initial support
>
> Hamad Kadmany (1):
>   wil6210: Set permanent MAC address to wiphy
>
> Lior David (9):
>   wil6210: add support for discovery mode during scan
>   wil6210: switch to generated wmi.h
>   wil6210: basic PBSS/PCP support
>   wil6210: P2P_DEVICE virtual interface support
>   wil6210: fix race conditions in p2p listen and search
>   wil6210: clean ioctl debug message
>   wil6210: fix no_fw_recovery mode with change_virtual_intf
>   wil6210: pass is_go flag to firmware
>   wil6210: add oob_mode module parameter
>
> Maya Erez (3):
>   wil6210: remove BACK RX and TX workers
>   wil6210: AP: prevent connecting to already connected station
>   wil6210: add support for platform specific notification events
>
> Vladimir Kondratiev (1):
>   wil6210: replay attack detection

All 15 applied to ath.git, thanks.

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About adding support for MT76x2U to Linux kernel

[Felix Fietkau]

On 2016-03-07 12:14, Johannes Stezenbach wrote:
> On Wed, Mar 02, 2016 at 09:32:10AM +0200, Tuomas Räsänen wrote:
>> On Fri, Aug 14, 2015 at 02:32:29PM +0200, Jakub Kiciński wrote:
>> > CC: Linus W who was hacking on mt7630e recently.
>> > 
>> > There is a fourth option: merge mt76 and mt7601u and add support for
>> > mt76x2u along the way ;)
>> 
>> Btw, how difficult it would be to add master mode support to mt7601u?
>> 
>> From 1 to 5, where 1 corresponds to "I know what I do, just give me
>> couple of days, no interruptions" and 5 corresponds to the work you
>> had to make to get mt7601u to its current shape?
> 
> I can't answer that question, but I've spent time studying
> the various drivers in preparation for adding support
> for mt7610u, my conclusion is the hardware is similar
> to mt76x2e (same MAC, same RF) so for me that's the way to go.
> 
> The big drawback of the USB devices is the lack of interrupts,
> especially no TBTT and PRE_TBTT, so it's not clear how to
> support AP mode properly.  FWIW, the mt7610u vendor driver
> doesn't support AP mode, while the mt7612u vendor driver does,
> but I didn't understand how their timing of sending buffered
> frames works.
Where can I find the most recent version of that vendor driver?
I can take a quick look at it.

> Another concern is the handling of the TX status since there
> is also no TX_STAT interrupt.  I remember from rt2800usb
> it was always problematic to ensure no FIFO items were lost,
> which is a problem for rt2800usb since it doesn't report
> TX status before it got it from the hardware.
> The mt7601u driver takes the approach to report IEEE80211_TX_STAT_ACK
> immediately after urb completion, and send the real
> status later from a delayed workqueue in mt7601u_tx_stat().
> Could someone enlighten me if this approach is sane
> wrt to minstrel rate control?
When I started writing mt76 I did lots of experiments with trying to map
TX_STAT_FIFO data to individual frames and pretty much gave up, because
the status register was just too unreliable. Even in cases where it was
reliable, mapping the status info to frames is expensive on slower
embedded hardware, so I pretty much gave up on that approach and
extended the rate control API to support submitting tx status
information without the corresponding skb.

This turned out to work quite well, and I think it might be worth using
to some extent even on drivers with proper skb tx status reporting,
since it has better cache footprint and has to run less code.

I think the best approach is to try to map tx status info from
TX_STAT_FIFO in cases where IEEE80211_TX_CTL_REQ_TX_STATUS is set, and
just use ieee80211_tx_status_noskb for all other frames. I did something
like that on my work-in-progress mt7603 code.

- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About adding support for MT76x2U to Linux kernel

[Johannes Stezenbach]

On Wed, Mar 02, 2016 at 09:32:10AM +0200, Tuomas Räsänen wrote:
> On Fri, Aug 14, 2015 at 02:32:29PM +0200, Jakub Kiciński wrote:
> > CC: Linus W who was hacking on mt7630e recently.
> > 
> > There is a fourth option: merge mt76 and mt7601u and add support for
> > mt76x2u along the way ;)
> 
> Btw, how difficult it would be to add master mode support to mt7601u?
> 
> From 1 to 5, where 1 corresponds to "I know what I do, just give me
> couple of days, no interruptions" and 5 corresponds to the work you
> had to make to get mt7601u to its current shape?

I can't answer that question, but I've spent time studying
the various drivers in preparation for adding support
for mt7610u, my conclusion is the hardware is similar
to mt76x2e (same MAC, same RF) so for me that's the way to go.

The big drawback of the USB devices is the lack of interrupts,
especially no TBTT and PRE_TBTT, so it's not clear how to
support AP mode properly.  FWIW, the mt7610u vendor driver
doesn't support AP mode, while the mt7612u vendor driver does,
but I didn't understand how their timing of sending buffered
frames works.

Another concern is the handling of the TX status since there
is also no TX_STAT interrupt.  I remember from rt2800usb
it was always problematic to ensure no FIFO items were lost,
which is a problem for rt2800usb since it doesn't report
TX status before it got it from the hardware.
The mt7601u driver takes the approach to report IEEE80211_TX_STAT_ACK
immediately after urb completion, and send the real
status later from a delayed workqueue in mt7601u_tx_stat().
Could someone enlighten me if this approach is sane
wrt to minstrel rate control?

The mt7610u vendor driver doesn't use the TX_STAT_FIFO at
all (it has code to read it but it is bypassed for mt7610u),
its rate control relies on the statistic registers only.


Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1] cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

Add support for new netlink attribute 'NL80211_STA_INFO_RX_DURATION'
This flag will be set when drivers can fill rx_duration (vendor
specific total air time(usecs) for data/management frames from the
connected client) via 'drv_sta_statistics' callback

Also make sta_info flags 'filled' as 64 bit to accommodate for new
per station stats. Extend 'PUT_SINFO' for supporting rx_duration
field and any new per sta information in future

Signed-off-by: Mohammed Shafi Shajakhan 
---
[v1] 
1. Fixed typo for accommodate
2. changed the doc for rx_duration as 'vendor specific implementation'

 include/net/cfg80211.h   |5 -
 include/uapi/linux/nl80211.h |3 +++
 net/wireless/nl80211.c   |3 ++-
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9bcaaf7..2db26a9 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1060,11 +1060,13 @@ struct cfg80211_tid_stats {
  * @rx_beacon: number of beacons received from this peer
  * @rx_beacon_signal_avg: signal strength average (in dBm) for beacons received
  * from this peer
+ * @rx_duration: vendor specific total air time(usecs) for data/management
+ * frames from the connected client
  * @pertid: per-TID statistics, see  cfg80211_tid_stats, using the last
  * (IEEE80211_NUM_TIDS) index for MSDUs not encapsulated in QoS-MPDUs.
  */
 struct station_info {
-   u32 filled;
+   u64 filled;
u32 connected_time;
u32 inactive_time;
u64 rx_bytes;
@@ -1103,6 +1105,7 @@ struct station_info {
u32 expected_throughput;
 
u64 rx_beacon;
+   u64 rx_duration;
u8 rx_beacon_signal_avg;
struct cfg80211_tid_stats pertid[IEEE80211_NUM_TIDS + 1];
 };
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 5b7b5eb..f64a854 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2464,6 +2464,8 @@ enum nl80211_sta_bss_param {
  * TID+1 and the special TID 16 (i.e. value 17) is used for non-QoS frames;
  * each one of those is again nested with  nl80211_tid_stats
  * attributes carrying the actual values.
+ * @NL80211_STA_INFO_RX_DURATION: vendor specific total air time(usecs) for
+ * data/management frames from the connected client
  * @__NL80211_STA_INFO_AFTER_LAST: internal
  * @NL80211_STA_INFO_MAX: highest possible station info attribute
  */
@@ -2500,6 +2502,7 @@ enum nl80211_sta_info {
NL80211_STA_INFO_BEACON_RX,
NL80211_STA_INFO_BEACON_SIGNAL_AVG,
NL80211_STA_INFO_TID_STATS,
+   NL80211_STA_INFO_RX_DURATION,
 
/* keep last */
__NL80211_STA_INFO_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d4786f2..a81c016 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3719,7 +3719,7 @@ static int nl80211_send_station(struct sk_buff *msg, u32 
cmd, u32 portid,
goto nla_put_failure;
 
 #define PUT_SINFO(attr, memb, type) do {   \
-   if (sinfo->filled & BIT(NL80211_STA_INFO_ ## attr) &&   \
+   if (sinfo->filled & (1ULL << NL80211_STA_INFO_ ## attr) &&  \
nla_put_ ## type(msg, NL80211_STA_INFO_ ## attr,\
 sinfo->memb))  \
goto nla_put_failure;   \
@@ -3745,6 +3745,7 @@ static int nl80211_send_station(struct sk_buff *msg, u32 
cmd, u32 portid,
PUT_SINFO(LLID, llid, u16);
PUT_SINFO(PLID, plid, u16);
PUT_SINFO(PLINK_STATE, plink_state, u8);
+   PUT_SINFO(RX_DURATION, rx_duration, u64);
 
switch (rdev->wiphy.signal_type) {
case CFG80211_SIGNAL_TYPE_MBM:
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1] iw: Add support for NL80211_STA_INFO_RX_DURATION netlink attribute

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

Enable support for parsing per station rx-duration (usecs)
via adding support for new netlink attribute NL80211_STA_INFO_RX_DURATION

rx_duration is vendor specific total air time(usecs) for data/management
frames from the connected client. This will get dumped as
part of 'iw dev wlan#N station dump'

Signed-off-by: Mohammed Shafi Shajakhan 
---
[v1]

changed the doc for rx_duration as 'vendor specific implementation'

 nl80211.h |3 +++
 station.c |5 +
 2 files changed, 8 insertions(+)

diff --git a/nl80211.h b/nl80211.h
index 5b7b5eb..3aeb2c6 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -2464,6 +2464,8 @@ enum nl80211_sta_bss_param {
  * TID+1 and the special TID 16 (i.e. value 17) is used for non-QoS frames;
  * each one of those is again nested with  nl80211_tid_stats
  * attributes carrying the actual values.
+ * @NL80210_STA_INFO_RX_DURATION: vendor specific total airtime(usecs) for
+ * data/management frames from the connected client
  * @__NL80211_STA_INFO_AFTER_LAST: internal
  * @NL80211_STA_INFO_MAX: highest possible station info attribute
  */
@@ -2500,6 +2502,7 @@ enum nl80211_sta_info {
NL80211_STA_INFO_BEACON_RX,
NL80211_STA_INFO_BEACON_SIGNAL_AVG,
NL80211_STA_INFO_TID_STATS,
+   NL80211_STA_INFO_RX_DURATION,
 
/* keep last */
__NL80211_STA_INFO_AFTER_LAST,
diff --git a/station.c b/station.c
index b5ccf4a..a730db1 100644
--- a/station.c
+++ b/station.c
@@ -147,6 +147,7 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
[NL80211_STA_INFO_NONPEER_PM] = { .type = NLA_U32},
[NL80211_STA_INFO_CHAIN_SIGNAL] = { .type = NLA_NESTED },
[NL80211_STA_INFO_CHAIN_SIGNAL_AVG] = { .type = NLA_NESTED },
+   [NL80211_STA_INFO_RX_DURATION] = { .type = NLA_U64 },
};
char *chain;
 
@@ -226,6 +227,10 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
printf("\n\trx bitrate:\t%s", buf);
}
 
+   if (sinfo[NL80211_STA_INFO_RX_DURATION])
+   printf("\n\trx duration:\t%lld us",
+  (unsigned long 
long)nla_get_u64(sinfo[NL80211_STA_INFO_RX_DURATION]));
+
if (sinfo[NL80211_STA_INFO_EXPECTED_THROUGHPUT]) {
uint32_t thr;
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rt2x00queue: rt2800usb: NULL pointer crash while during USB disconnect

[Vishal Thanki]

On Mon, Mar 7, 2016 at 10:59 AM, Stanislaw Gruszka  wrote:
> Hi,
>
> On Tue, Mar 01, 2016 at 11:36:13AM +0100, Vishal Thanki wrote:
>> I observed a NULL pointer access crash during my testing on a custom AM33xx
>> based board with RT5572 USB wifi module. The kernel log is attached with
>> the mail. With initial debugging, I think that the USB disconnect
>> event was triggered while there was an pending/incomplete URB request
>> present. As a part of USB disconnect, the driver cleanup deallocated
>> queues. However the completion of pending URB tried to access the queue,
>> which resulted in the NULL pointer crash.
>>
>> I added a check in the queue helper routines and with that I did not see
>> the problem. The patch for the same is also attached with the email.
>> Please suggest if that is the right way to address the problem.
>
> Fix is not correct as we can crash at any other point if we get callback
> from pending urb after resources are freed. What should be done is
> create a list of pending urbs (possibly using usb_anchor structure and
> primitives) and kill urb's before freeing resources.
>

Thank you for the reply. I will prepare the patch as suggested.

Vishal

> Stanislaw
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rt2x00queue: rt2800usb: NULL pointer crash while during USB disconnect

[Stanislaw Gruszka]

Hi,

On Tue, Mar 01, 2016 at 11:36:13AM +0100, Vishal Thanki wrote:
> I observed a NULL pointer access crash during my testing on a custom AM33xx
> based board with RT5572 USB wifi module. The kernel log is attached with
> the mail. With initial debugging, I think that the USB disconnect
> event was triggered while there was an pending/incomplete URB request
> present. As a part of USB disconnect, the driver cleanup deallocated
> queues. However the completion of pending URB tried to access the queue,
> which resulted in the NULL pointer crash.
> 
> I added a check in the queue helper routines and with that I did not see
> the problem. The patch for the same is also attached with the email.
> Please suggest if that is the right way to address the problem.

Fix is not correct as we can crash at any other point if we get callback
from pending urb after resources are freed. What should be done is
create a list of pending urbs (possibly using usb_anchor structure and
primitives) and kill urb's before freeing resources.

Stanislaw
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ath10k: fix HTT Tx CE ring size

[Valo, Kalle]

Michal Kazior  writes:

> QCA4019 can queue up to 2500 frames at a time.
> This means it requires roughly 5000 entires on the
> ring to work properly. Otherwise random tx failure
> may occur.
>
> Signed-off-by: Michal Kazior 

Both patches applied, thanks.

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rt2x00: add new rt2800usb device Buffalo WLI-UC-G450

[Stanislaw Gruszka]

On Tue, Feb 23, 2016 at 11:09:22PM +0800, Anthony Wong wrote:
> Add USB ID 0411:01fd for Buffalo WLI-UC-G450 wireless adapter,
> RT chipset 3593
> 
> Signed-off-by: Anthony Wong 
> Cc: sta...@vger.kernel.org
Acked-by: Stanislaw Gruszka 

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 07/11] ath10k: implement wake_tx_queue

[Valo, Kalle]

Michal Kazior  writes:

> On 6 March 2016 at 15:27, Valo, Kalle  wrote:
>> Michal Kazior  writes:
>>
>>> This implements very basic support for software
>>> queueing. It also contains some knobs that will be
>>> patched later.
>>>
>>> Signed-off-by: Michal Kazior 
>>
>> Oddly this patch introduces a new warning:
>>
>> drivers/net/wireless/ath/ath10k/mac.c: In function ath10k_mac_op_tx:
>> drivers/net/wireless/ath/ath10k/mac.c:3949:29: warning: is_mgmt may be used 
>> uninitialized in this function [-Wuninitialized]
>>
>> But I think that's just a false warning, most likely because my gcc is
>> ancient. Do you agree?
>
> Yes, I agree. It must be the fact is_mgmt is set/used across two
> is_htt condition branches.
>
>
>> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
>
> gcc (Debian 4.9.2-10) 4.9.2 -- no warning for me.

Actually kbuild also found this but let's just ignore it.

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html