Re: [PATCH] cfg80211/nl80211: Add support for NL80211_STA_INFO_RX_DURATION
Hi Johannes, https://groups.google.com/a/chromium.org/forum/#!msg/chromium-os-reviews/lDzKxgl6fIE/H5GQfMcuBwAJ for more information regarding the request for implementation. I will send a v2 re-phrasing that it is implementation specific. regards, shafi On Thu, Mar 03, 2016 at 09:50:36PM +0530, Mohammed Shafi Shajakhan wrote: > Hi johannes, > > On Thu, Mar 03, 2016 at 05:07:51PM +0100, Johannes Berg wrote: > > On Thu, 2016-03-03 at 21:30 +0530, Mohammed Shafi Shajakhan wrote: > > > > > [shafi] This is part of the Per Station statistics requirement, > > > > Heh. Whose requirements? :) > > [shafi] We have this as part of ath10k debugfs based on the end user (or) a > customer requirement and i think its make more sense to have this common > across all > wifi drivers rather thank simply dumping it in ath10k debugfs. I think its > similar to 'ieee80211_frame_duration'(?) in mac80211 but for drivers like > ath10k > where this is calculated in firmware for rx and implementation specific. > > > > > > the information from 'iw dev wlan#N station dump' which has > > > rx_duration > > > field will be used by application assesing the statistics > > > /performance of various clients connected to our AP. We will plot > > > a graph based on this information (assesing the rx time spent by > > > AP for various clients). > > > > > > > > > > > Are you really sure you mean "unicast"? What if the station is the > > > > AP? Why wouldn't multicast frames it transmitted be accounted for? > > > > > > [shafi] This is based on the implementation by the driver/firmware. > > > We are focused on the AP side so unicast frames, if you are ok with > > > this change, i can change the documentation to be specific (generic > > > for all the drivers) something like implementation specific (please > > > advise) > > > > Ok, but for AP side I don't see the difference between "unicast" and > > "all frames", since all frames from that station should be unicast? > > Apart, perhaps, from some management frames the station might send > > outside the BSS, but that's not likely to matter much? > > [shafi] exactly, I can change the documentation as you wish and > this is implementation specific, and we have implemented like this in ath10k > targeting AP mode. > > > > > IOW, why not specify all frames, and let this make some sense for other > > interface modes? > > > [shafi] Agreed. > > regards, > shafi > -- > 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 -- 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] ath10k: move mgmt descriptor limit handle under mgmt_tx
Firmware reserves few descriptors for management frames transmission.
In 16 MBSSID scenario, these slots will be easy exhausted due to frequent
probe responses. So for 10.4 based solutions, probe responses are limited
by a threshold (24).
management tx path is separate for all except tlv based solutions. Since
tlv solutions (qca6174 & qca9377) do not support 16 AP interfaces, it is
safe to move management descriptor limitation check under mgmt_tx
function. Though CPU improvement is negligible, unlikely conditions or
never hit conditions in hot path can be avoided on data transmission.
Signed-off-by: Rajkumar Manoharan
---
drivers/net/wireless/ath/ath10k/htt.h| 2 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 7 +++-
drivers/net/wireless/ath/ath10k/htt_tx.c | 62
drivers/net/wireless/ath/ath10k/txrx.c | 18 --
drivers/net/wireless/ath/ath10k/txrx.h | 4 +--
5 files changed, 38 insertions(+), 55 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 13391ea..b611c2b 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1753,7 +1753,7 @@ int ath10k_htt_h2t_aggr_cfg_msg(struct ath10k_htt *htt,
u8 max_subfrms_amsdu);
void ath10k_htt_hif_tx_complete(struct ath10k *ar, struct sk_buff *skb);
-void __ath10k_htt_tx_dec_pending(struct ath10k_htt *htt, bool limit_mgmt_desc);
+void __ath10k_htt_tx_dec_pending(struct ath10k_htt *htt);
int ath10k_htt_tx_alloc_msdu_id(struct ath10k_htt *htt, struct sk_buff *skb);
void ath10k_htt_tx_free_msdu_id(struct ath10k_htt *htt, u16 msdu_id);
int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct sk_buff *);
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index ae9b686..7d1a0f2 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2049,7 +2049,12 @@ void ath10k_htt_t2h_msg_handler(struct ath10k *ar,
struct sk_buff *skb)
break;
}
- ath10k_txrx_tx_unref(htt, &tx_done);
+ status = ath10k_txrx_tx_unref(htt, &tx_done);
+ if (!status) {
+ spin_lock_bh(&htt->tx_lock);
+ htt->num_pending_mgmt_tx--;
+ spin_unlock_bh(&htt->tx_lock);
+ }
break;
}
case HTT_T2H_MSG_TYPE_TX_COMPL_IND:
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 95acb72..6a29b802 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -22,28 +22,22 @@
#include "txrx.h"
#include "debug.h"
-void __ath10k_htt_tx_dec_pending(struct ath10k_htt *htt, bool limit_mgmt_desc)
+void __ath10k_htt_tx_dec_pending(struct ath10k_htt *htt)
{
- if (limit_mgmt_desc)
- htt->num_pending_mgmt_tx--;
-
htt->num_pending_tx--;
if (htt->num_pending_tx == htt->max_num_pending_tx - 1)
ath10k_mac_tx_unlock(htt->ar, ATH10K_TX_PAUSE_Q_FULL);
}
-static void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt,
- bool limit_mgmt_desc)
+static void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt)
{
spin_lock_bh(&htt->tx_lock);
- __ath10k_htt_tx_dec_pending(htt, limit_mgmt_desc);
+ __ath10k_htt_tx_dec_pending(htt);
spin_unlock_bh(&htt->tx_lock);
}
-static int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt,
-bool limit_mgmt_desc, bool is_probe_resp)
+static int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt)
{
- struct ath10k *ar = htt->ar;
int ret = 0;
spin_lock_bh(&htt->tx_lock);
@@ -53,15 +47,6 @@ static int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt,
goto exit;
}
- if (limit_mgmt_desc) {
- if (is_probe_resp && (htt->num_pending_mgmt_tx >
- ar->hw_params.max_probe_resp_desc_thres)) {
- ret = -EBUSY;
- goto exit;
- }
- htt->num_pending_mgmt_tx++;
- }
-
htt->num_pending_tx++;
if (htt->num_pending_tx == htt->max_num_pending_tx)
ath10k_mac_tx_lock(htt->ar, ATH10K_TX_PAUSE_Q_FULL);
@@ -576,17 +561,21 @@ int ath10k_htt_mgmt_tx(struct ath10k_htt *htt, struct
sk_buff *msdu)
int msdu_id = -1;
int res;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)msdu->data;
- bool limit_mgmt_desc = false;
- bool is_probe_resp = false;
-
- if (ar->hw_params.max_probe_resp_desc_thres) {
- limit_mgmt_desc = true;
- if (ieee80211_is_probe_resp(hdr->frame_control))
- is_probe_resp = true;
+ if (ar->hw_params.max_probe_resp_desc_thres &&
Re: [PATCH] ath10k: move mgmt descriptor limit handle under mgmt_tx
On 03/05/2016 06:10 AM, Rajkumar Manoharan wrote: Firmware reserves few descriptors for management frames transmission. In 16 MBSSID scenario, these slots will be easy exhausted due to frequent probe responses. So for 10.4 based solutions, probe responses are limited by a threshold (24). Do you mean probe requests or probe responses? A single hardware scan request with lots of ssids in it will utilize all firmware tx management frames (which is 5, it seems). In my testing, the firmware would just never send probe requests for the rest of the ssids because the firmware scan state machine logic is broken. If you really do mean responses, then it sounds like it would be better to use the normal RX path for mgt frames in the firmware... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- 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] iw: add libnl-tiny support, reimplemented
This allows small static builds, especially when using musl libc.
Signed-off-by: Dima Krasner
---
Makefile | 8
iw.c | 4 ++--
iw.h | 2 +-
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index e61825e..4077020 100644
--- a/Makefile
+++ b/Makefile
@@ -27,6 +27,8 @@ OBJS += $(OBJS-y) $(OBJS-Y)
ALL = iw
ifeq ($(NO_PKG_CONFIG),)
+NLTINYFOUND := $(shell $(PKG_CONFIG) libnl-tiny && echo Y)
+ifneq ($(NLTINYFOUND),Y)
NL3xFOUND := $(shell $(PKG_CONFIG) --atleast-version=3.2 libnl-3.0 && echo Y)
ifneq ($(NL3xFOUND),Y)
NL31FOUND := $(shell $(PKG_CONFIG) --exact-version=3.1 libnl-3.1 && echo Y)
@@ -40,6 +42,12 @@ endif
endif
endif
endif
+endif
+
+ifeq ($(NLTINYFOUND),Y)
+CFLAGS += -DCONFIG_LIBNL_TINY
+NLLIBNAME = libnl-tiny
+endif
ifeq ($(NL1FOUND),Y)
NLLIBNAME = libnl-1
diff --git a/iw.c b/iw.c
index 0f511d9..c52d7ba 100644
--- a/iw.c
+++ b/iw.c
@@ -24,7 +24,7 @@
#include "iw.h"
/* libnl 1.x compatibility code */
-#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
+#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30) &&
!defined(CONFIG_LIBNL_TINY)
static inline struct nl_handle *nl_socket_alloc(void)
{
return nl_handle_alloc();
@@ -40,7 +40,7 @@ static inline int nl_socket_set_buffer_size(struct nl_sock
*sk,
{
return nl_set_buffer_size(sk, rxbuf, txbuf);
}
-#endif /* CONFIG_LIBNL20 && CONFIG_LIBNL30 */
+#endif /* CONFIG_LIBNL20 && CONFIG_LIBNL30 && CONFIG_LIBNL_TINY */
int iw_debug = 0;
diff --git a/iw.h b/iw.h
index d91a33e..37757d4 100644
--- a/iw.h
+++ b/iw.h
@@ -13,7 +13,7 @@
#define ETH_ALEN 6
-/* libnl 1.x compatibility code */
+/* libnl 1.x and libnl-tiny compatibility code */
#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
# define nl_sock nl_handle
#endif
--
2.1.4
--
Dima Krasner
--
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] iw: add libnl-tiny support
On Wed, 02 Mar 2016 14:59:36 +0100
Johannes Berg wrote:
> you should work with that code instead of redefining
> everything.
Done.
(I sent this patch in a new thread earlier, because I couldn't find your reply
in my inbox. Sorry for that.)
Signed-off-by: Dima Krasner
---
Makefile | 8
iw.c | 4 ++--
iw.h | 2 +-
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index e61825e..4077020 100644
--- a/Makefile
+++ b/Makefile
@@ -27,6 +27,8 @@ OBJS += $(OBJS-y) $(OBJS-Y)
ALL = iw
ifeq ($(NO_PKG_CONFIG),)
+NLTINYFOUND := $(shell $(PKG_CONFIG) libnl-tiny && echo Y)
+ifneq ($(NLTINYFOUND),Y)
NL3xFOUND := $(shell $(PKG_CONFIG) --atleast-version=3.2 libnl-3.0 && echo Y)
ifneq ($(NL3xFOUND),Y)
NL31FOUND := $(shell $(PKG_CONFIG) --exact-version=3.1 libnl-3.1 && echo Y)
@@ -40,6 +42,12 @@ endif
endif
endif
endif
+endif
+
+ifeq ($(NLTINYFOUND),Y)
+CFLAGS += -DCONFIG_LIBNL_TINY
+NLLIBNAME = libnl-tiny
+endif
ifeq ($(NL1FOUND),Y)
NLLIBNAME = libnl-1
diff --git a/iw.c b/iw.c
index 0f511d9..c52d7ba 100644
--- a/iw.c
+++ b/iw.c
@@ -24,7 +24,7 @@
#include "iw.h"
/* libnl 1.x compatibility code */
-#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
+#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30) &&
!defined(CONFIG_LIBNL_TINY)
static inline struct nl_handle *nl_socket_alloc(void)
{
return nl_handle_alloc();
@@ -40,7 +40,7 @@ static inline int nl_socket_set_buffer_size(struct nl_sock
*sk,
{
return nl_set_buffer_size(sk, rxbuf, txbuf);
}
-#endif /* CONFIG_LIBNL20 && CONFIG_LIBNL30 */
+#endif /* CONFIG_LIBNL20 && CONFIG_LIBNL30 && CONFIG_LIBNL_TINY */
int iw_debug = 0;
diff --git a/iw.h b/iw.h
index d91a33e..37757d4 100644
--- a/iw.h
+++ b/iw.h
@@ -13,7 +13,7 @@
#define ETH_ALEN 6
-/* libnl 1.x compatibility code */
+/* libnl 1.x and libnl-tiny compatibility code */
#if !defined(CONFIG_LIBNL20) && !defined(CONFIG_LIBNL30)
# define nl_sock nl_handle
#endif
--
2.1.4
--
Dima Krasner
--
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] ath10k: move mgmt descriptor limit handle under mgmt_tx
On , Ben Greear wrote:
On 03/05/2016 06:10 AM, Rajkumar Manoharan wrote:
Firmware reserves few descriptors for management frames transmission.
In 16 MBSSID scenario, these slots will be easy exhausted due to
frequent
probe responses. So for 10.4 based solutions, probe responses are
limited
by a threshold (24).
Do you mean probe requests or probe responses?
I meant probe responses in AP mode.
A single hardware scan request with lots of ssids in it will utilize
all
firmware tx management frames (which is 5, it seems). In my testing,
the
firmware would just never send probe requests for the rest of the ssids
because the firmware scan state machine logic is broken.
Hmm... firmware expects both ssid and bssid list to be filled for
multiple probe
requests. Better to try with different probe spacing time, repeat probe
time and
probe delay and dwell time as these params change prob_req behavior in
firmware.
Anyway this change is not related to scan functionality.
If you really do mean responses, then it sounds like it would be better
to
use the normal RX path for mgt frames in the firmware...
Let me clarify. Sending probe responses in AP mode are limited by a
threshold
for qca99x0 ("ath10k: drop probe responses when too many are queued").
This change
moves probe response checks under mgmt_tx from common data path.
-Rajkumar
--
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] ath10k: move mgmt descriptor limit handle under mgmt_tx
On 03/05/2016 08:00 PM, Rajkumar Manoharan wrote:
On , Ben Greear wrote:
On 03/05/2016 06:10 AM, Rajkumar Manoharan wrote:
Firmware reserves few descriptors for management frames transmission.
In 16 MBSSID scenario, these slots will be easy exhausted due to frequent
probe responses. So for 10.4 based solutions, probe responses are limited
by a threshold (24).
Do you mean probe requests or probe responses?
I meant probe responses in AP mode.
A single hardware scan request with lots of ssids in it will utilize all
firmware tx management frames (which is 5, it seems). In my testing, the
firmware would just never send probe requests for the rest of the ssids
because the firmware scan state machine logic is broken.
Hmm... firmware expects both ssid and bssid list to be filled for multiple probe
requests. Better to try with different probe spacing time, repeat probe time and
probe delay and dwell time as these params change prob_req behavior in firmware.
It was easier to just fix the firmware than to hack the
rest of the stack.
Anyway this change is not related to scan functionality.
If you really do mean responses, then it sounds like it would be better to
use the normal RX path for mgt frames in the firmware...
Let me clarify. Sending probe responses in AP mode are limited by a threshold
for qca99x0 ("ath10k: drop probe responses when too many are queued"). This
change
moves probe response checks under mgmt_tx from common data path.
Ok, I'll take a look at that. I've implemented MGT frames over the completely
normal HTT data-path transport, so probably I won't hit that in my systems
anyway (there should be no internal mgt-frame limitation, except for locally
created things like probe requests during scan). But, I could be missing
something...I'm really just getting started with 10.4...
Thanks,
Ben
-Rajkumar
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
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] ath10k: move mgmt descriptor limit handle under mgmt_tx
On , Ben Greear wrote:
On 03/05/2016 08:00 PM, Rajkumar Manoharan wrote:
On , Ben Greear wrote:
On 03/05/2016 06:10 AM, Rajkumar Manoharan wrote:
Firmware reserves few descriptors for management frames
transmission.
In 16 MBSSID scenario, these slots will be easy exhausted due to
frequent
probe responses. So for 10.4 based solutions, probe responses are
limited
by a threshold (24).
Do you mean probe requests or probe responses?
I meant probe responses in AP mode.
A single hardware scan request with lots of ssids in it will utilize
all
firmware tx management frames (which is 5, it seems). In my testing,
the
firmware would just never send probe requests for the rest of the
ssids
because the firmware scan state machine logic is broken.
Hmm... firmware expects both ssid and bssid list to be filled for
multiple probe
requests. Better to try with different probe spacing time, repeat
probe time and
probe delay and dwell time as these params change prob_req behavior in
firmware.
It was easier to just fix the firmware than to hack the
rest of the stack.
I didn't mean to hack the stack :) but scan params should not be
constant for all type
of scan requests.
Anyway this change is not related to scan functionality.
If you really do mean responses, then it sounds like it would be
better to
use the normal RX path for mgt frames in the firmware...
Let me clarify. Sending probe responses in AP mode are limited by a
threshold
for qca99x0 ("ath10k: drop probe responses when too many are queued").
This change
moves probe response checks under mgmt_tx from common data path.
Ok, I'll take a look at that. I've implemented MGT frames over the
completely
normal HTT data-path transport, so probably I won't hit that in my
systems
anyway (there should be no internal mgt-frame limitation, except for
locally
created things like probe requests during scan). But, I could be
missing
something...I'm really just getting started with 10.4...
Great.. just noticed that this change needs to be rebased on top of
Michal's recent
data path series. Let me send next version.
-Rajkumar
--
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] mac80211: remove wdev/vif conversion functions
On Fri, Feb 26, 2016 at 11:14 PM, Felix Fietkau wrote:
> Nothing uses them
Correction: nothing *upstream* uses them *yet*. We have code that will use them.
wdev_to_ieee80211_vif was added by:
commit ad7e718c9b4f717823fd920a0103f7b0fb06183f
Author: Johannes Berg
Date: Wed Nov 13 13:37:47 2013 +0100
nl80211: vendor command support
Which by design was meant to provide a pipe that may not be upstream
(at least not immediately).
>
> Signed-off-by: Felix Fietkau
> ---
> include/net/mac80211.h | 26 --
> net/mac80211/util.c| 28
> 2 files changed, 54 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 0c09da3..e11d751 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -1439,32 +1439,6 @@ static inline bool ieee80211_vif_is_mesh(struct
> ieee80211_vif *vif)
> }
>
> /**
> - * wdev_to_ieee80211_vif - return a vif struct from a wdev
> - * @wdev: the wdev to get the vif for
> - *
> - * This can be used by mac80211 drivers with direct cfg80211 APIs
> - * (like the vendor commands) that get a wdev.
> - *
> - * Note that this function may return %NULL if the given wdev isn't
> - * associated with a vif that the driver knows about (e.g. monitor
> - * or AP_VLAN interfaces.)
> - */
> -struct ieee80211_vif *wdev_to_ieee80211_vif(struct wireless_dev *wdev);
> -
> -/**
> - * ieee80211_vif_to_wdev - return a wdev struct from a vif
> - * @vif: the vif to get the wdev for
> - *
> - * This can be used by mac80211 drivers with direct cfg80211 APIs
> - * (like the vendor commands) that needs to get the wdev for a vif.
> - *
> - * Note that this function may return %NULL if the given wdev isn't
> - * associated with a vif that the driver knows about (e.g. monitor
> - * or AP_VLAN interfaces.)
> - */
> -struct wireless_dev *ieee80211_vif_to_wdev(struct ieee80211_vif *vif);
> -
> -/**
> * enum ieee80211_key_flags - key flags
> *
> * These flags are used for communication about keys between the driver
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 89f7179..4482625 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -694,34 +694,6 @@ void ieee80211_iterate_stations_atomic(struct
> ieee80211_hw *hw,
> }
> EXPORT_SYMBOL_GPL(ieee80211_iterate_stations_atomic);
>
> -struct ieee80211_vif *wdev_to_ieee80211_vif(struct wireless_dev *wdev)
> -{
> - struct ieee80211_sub_if_data *sdata = IEEE80211_WDEV_TO_SUB_IF(wdev);
> -
> - if (!ieee80211_sdata_running(sdata) ||
> - !(sdata->flags & IEEE80211_SDATA_IN_DRIVER))
> - return NULL;
> - return &sdata->vif;
> -}
> -EXPORT_SYMBOL_GPL(wdev_to_ieee80211_vif);
> -
> -struct wireless_dev *ieee80211_vif_to_wdev(struct ieee80211_vif *vif)
> -{
> - struct ieee80211_sub_if_data *sdata;
> -
> - if (!vif)
> - return NULL;
> -
> - sdata = vif_to_sdata(vif);
> -
> - if (!ieee80211_sdata_running(sdata) ||
> - !(sdata->flags & IEEE80211_SDATA_IN_DRIVER))
> - return NULL;
> -
> - return &sdata->wdev;
> -}
> -EXPORT_SYMBOL_GPL(ieee80211_vif_to_wdev);
> -
> /*
> * Nothing should have been stuffed into the workqueue during
> * the suspend->resume cycle. Since we can't check each caller
> --
> 2.2.2
>
> --
> 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
--
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 v2] ath10k: move mgmt descriptor limit handle under mgmt_tx
Firmware reserves few descriptors for management frames transmission.
In 16 MBSSID scenario, these slots will be easy exhausted due to frequent
probe responses. So for 10.4 based solutions, probe responses are limited
by a threshold (24).
management tx path is separate for all except tlv based solutions. Since
tlv solutions (qca6174 & qca9377) do not support 16 AP interfaces, it is
safe to move management descriptor limitation check under mgmt_tx
function. Though CPU improvement is negligible, unlikely conditions or
never hit conditions in hot path can be avoided on data transmission.
Signed-off-by: Rajkumar Manoharan
---
v2:
- rebased on top of Michal changes
drivers/net/wireless/ath/ath10k/htt.h| 9 ---
drivers/net/wireless/ath/ath10k/htt_rx.c | 7 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 41 +++-
drivers/net/wireless/ath/ath10k/mac.c| 34 --
drivers/net/wireless/ath/ath10k/txrx.c | 18 ++
drivers/net/wireless/ath/ath10k/txrx.h | 4 ++--
6 files changed, 65 insertions(+), 48 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 02cf55d..26717e9 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1767,11 +1767,10 @@ void ath10k_htt_tx_txq_update(struct ieee80211_hw *hw,
void ath10k_htt_tx_txq_recalc(struct ieee80211_hw *hw,
struct ieee80211_txq *txq);
void ath10k_htt_tx_txq_sync(struct ath10k *ar);
-void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt,
- bool is_mgmt);
-int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt,
- bool is_mgmt,
- bool is_presp);
+void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt);
+int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt);
+void ath10k_htt_tx_mgmt_dec_pending(struct ath10k_htt *htt);
+int ath10k_htt_tx_mgmt_inc_pending(struct ath10k_htt *htt, bool is_presp);
int ath10k_htt_tx_alloc_msdu_id(struct ath10k_htt *htt, struct sk_buff *skb);
void ath10k_htt_tx_free_msdu_id(struct ath10k_htt *htt, u16 msdu_id);
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index adf35b0..9892f92 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2326,7 +2326,12 @@ void ath10k_htt_t2h_msg_handler(struct ath10k *ar,
struct sk_buff *skb)
break;
}
- ath10k_txrx_tx_unref(htt, &tx_done);
+ status = ath10k_txrx_tx_unref(htt, &tx_done);
+ if (!status) {
+ spin_lock_bh(&htt->tx_lock);
+ ath10k_htt_tx_mgmt_dec_pending(htt);
+ spin_unlock_bh(&htt->tx_lock);
+ }
ath10k_mac_tx_push_pending(ar);
break;
}
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index a30c34e..f2703bc 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -149,22 +149,30 @@ void ath10k_htt_tx_txq_update(struct ieee80211_hw *hw,
spin_unlock_bh(&ar->htt.tx_lock);
}
-void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt,
- bool is_mgmt)
+void ath10k_htt_tx_dec_pending(struct ath10k_htt *htt)
{
lockdep_assert_held(&htt->tx_lock);
- if (is_mgmt)
- htt->num_pending_mgmt_tx--;
-
htt->num_pending_tx--;
if (htt->num_pending_tx == htt->max_num_pending_tx - 1)
ath10k_mac_tx_unlock(htt->ar, ATH10K_TX_PAUSE_Q_FULL);
}
-int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt,
- bool is_mgmt,
- bool is_presp)
+int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt)
+{
+ lockdep_assert_held(&htt->tx_lock);
+
+ if (htt->num_pending_tx >= htt->max_num_pending_tx)
+ return -EBUSY;
+
+ htt->num_pending_tx++;
+ if (htt->num_pending_tx == htt->max_num_pending_tx)
+ ath10k_mac_tx_lock(htt->ar, ATH10K_TX_PAUSE_Q_FULL);
+
+ return 0;
+}
+
+int ath10k_htt_tx_mgmt_inc_pending(struct ath10k_htt *htt, bool is_presp)
{
struct ath10k *ar = htt->ar;
@@ -173,22 +181,23 @@ int ath10k_htt_tx_inc_pending(struct ath10k_htt *htt,
if (htt->num_pending_tx >= htt->max_num_pending_tx)
return -EBUSY;
- if (is_mgmt &&
- is_presp &&
+ if (is_presp &&
ar->hw_params.max_probe_resp_desc_thres &&
ar->hw_params.max_probe_resp_desc_thres < htt->num_pending_mgmt_tx)
return -EBUSY;
- if (is_mgmt)
- htt->num_pending_mgmt_tx++;
-
- htt->num_pending_tx++;
- if (htt->num_pending_tx == htt->max_num_pending_tx)
-
