[PATCH v2] rt2x00: add support for mac addr from device tree
On some devices the EEPROMs of Ralink Wi-Fi chips have a default Ralink
MAC address set (RT3062F: 00:0C:43:30:62:00, RT3060F:
00:0C:43:30:60:00). Using multiple of these devices in the same network
can cause nasty issues.
Allow to override the MAC in the EEPROM with (a known good) one set in
the device tree to bypass the issue.
Signed-off-by: Mathias Kresin
---
As discussed before, forcing a random MAC for known default MACs would
be a wonky approach. I wouldn't be surprise to see ODMs setting an ODM
specific default MAC in the EEPROM. This would require a permanent
update of the list of known default MACs.
Changes in v2:
- new commit message, the former one was incomprehensible
drivers/net/wireless/ralink/rt2x00/rt2400pci.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt2500pci.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt2x00.h| 1 +
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 17 +
drivers/net/wireless/ralink/rt2x00/rt61pci.c | 5 +
drivers/net/wireless/ralink/rt2x00/rt73usb.c | 5 +
8 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
index 155f343..085c5b4 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2400pci.c
@@ -1459,10 +1459,7 @@ static int rt2400pci_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
* Start validation of the data that has been read.
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
- if (!is_valid_ether_addr(mac)) {
- eth_random_addr(mac);
- rt2x00_eeprom_dbg(rt2x00dev, "MAC: %pM\n", mac);
- }
+ rt2x00lib_set_mac_address(rt2x00dev, mac);
rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
if (word == 0x) {
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
index 2553cdd..9832fd5 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500pci.c
@@ -1585,10 +1585,7 @@ static int rt2500pci_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
* Start validation of the data that has been read.
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
- if (!is_valid_ether_addr(mac)) {
- eth_random_addr(mac);
- rt2x00_eeprom_dbg(rt2x00dev, "MAC: %pM\n", mac);
- }
+ rt2x00lib_set_mac_address(rt2x00dev, mac);
rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
if (word == 0x) {
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
index 2d64611..cd3ab5a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
@@ -1349,10 +1349,7 @@ static int rt2500usb_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
* Start validation of the data that has been read.
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
- if (!is_valid_ether_addr(mac)) {
- eth_random_addr(mac);
- rt2x00_eeprom_dbg(rt2x00dev, "MAC: %pM\n", mac);
- }
+ rt2x00lib_set_mac_address(rt2x00dev, mac);
rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
if (word == 0x) {
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index bf3f0a3..59c49af 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -6919,10 +6919,7 @@ static int rt2800_validate_eeprom(struct rt2x00_dev
*rt2x00dev)
* Start validation of the data that has been read.
*/
mac = rt2800_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
- if (!is_valid_ether_addr(mac)) {
- eth_random_addr(mac);
- rt2x00_eeprom_dbg(rt2x00dev, "MAC: %pM\n", mac);
- }
+ rt2x00lib_set_mac_address(rt2x00dev, mac);
rt2800_eeprom_read(rt2x00dev, EEPROM_NIC_CONF0, &word);
if (word == 0x) {
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index f68d492..aa3d4cee 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -1403,6 +1403,7 @@ static inline void rt2x00debug_dump_frame(struct
rt2x00_dev *rt2x00dev,
*/
u32 rt2x00lib_get_bssidx(struct rt2x00_dev *rt2x00dev,
struct ieee80211_vif *vif);
+void rt2x00lib_set_mac_address(struct rt2x00_dev *rt2x00dev, u8
*eeprom_mac_addr);
/*
* Interrupt context handlers.
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index 4
Re: [PATCH v6] cfg80211: Provision to allow the support for different beacon intervals
Hi, Sorry - missed that mail somehow. > cfg80211_validate_beacon_int -> cfg80211_iter_combinations shall be > invoked for the interface combinations , currently. > diff_beacon_int_gcd_min is applicable for the interface combinations > and am not sure how can we validate this for a single interface . > This specific interface can be part of two different groups ( > interface combinations) with different values for > "diff_beacon_int_gcd_min". > I don't think we can get the match for the right set of combination > here , isn't ? Well if you have just a single interface, any combination that contains it is valid, so you'd just continue? I *think* the code works by checking if any combination applies to the currently desired state, and rejects if no combination is possible, that would still be perfectly reasonable here, no? > To make things simple , can we ignore the following rule > " When >0, any beacon interval must also be bigger than this value." > and rather have only the following one ? > " When >0, different beacon intervals must have a GCD that's at least > as big as this value." (To be more precise , any second interface > which does not meet this rule , will fail to start ) . Yeah, I suppose we could, but does that really make sense? If you can have a smaller BI, then you could as well have a smaller GCD, no? johannes
Re: [PATCH] cfg80211: Add HT and VHT information in start_ap
On Tue, 2016-08-16 at 12:34 +, Malinen, Jouni wrote: > > > So if you get HT_VHT_NOT_INDICATED in the driver, don't you *still* > > have to parse the IEs? > > Well.. Yes, I guess one would need to do that for some time until > relevant user space is expected to have been updated to support the > new attribute. So I guess the question is what drivers would use this, and how, and would we have to introduce this code into the kernel anyway? If yes, I'd argue it might as well be in cfg80211 instead of the driver(s). > I guess that could be considered reasonable approach for the existing > HT and VHT cases and new attributes would obviously be significantly > easier to introduce with new extensions (need to remember to do this > for HE from the beginning..). Indeed. I'll try to also remember :) > The parsing for these HT/VHT enabled/required is a bit strange > combination having to go over three IEs. I'm not sure a parsing > function to do so would be that nice.. The parsing code could indeed > be moved to cfg80211 so that it would not need to be duplicated into > each driver needing this, though. Right. johannes
[PATCH v5] ath10k: Fix broken NULL func data frame status for 10.4
From: Mohammed Shafi Shajakhan
Older firmware with HTT delivers incorrect tx status for null func
frames to driver, but this fixed in 10.2 and 10.4 firmware versions.
Also this workaround results in reporting of incorrect null func status
for 10.4. Fix this is by introducing a firmware feature flag for 10.4
so that this workaround is skipped and proper tx status for null func
frames are reported
Signed-off-by: Tamizh chelvam
Signed-off-by: Mohammed Shafi Shajakhan
---
[v5 based on the review comments from Michal]
drivers/net/wireless/ath/ath10k/core.c |1 +
drivers/net/wireless/ath/ath10k/core.h |7 +++
drivers/net/wireless/ath/ath10k/mac.c |2 ++
3 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index e889829..798b3f8 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -304,6 +304,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
[ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
[ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
[ATH10K_FW_FEATURE_BTCOEX_PARAM] = "btcoex-param",
+ [ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR] = "skip-null-func-war",
};
static unsigned int ath10k_core_get_fw_feature_str(char *buf,
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 30ae5bf..54e40f3 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -551,6 +551,13 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_BTCOEX_PARAM = 14,
+ /* Older firmware with HTT delivers incorrect tx status for null func
+* frames to driver, but this fixed in 10.2 and 10.4 firmware versions.
+* Also this workaround results in reporting of incorrect null func
+* status for 10.4. This flag is used to skip the workaround.
+*/
+ ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR = 15,
+
/* keep last */
ATH10K_FW_FEATURE_COUNT,
};
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index fb8e38d..7508ef8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3255,6 +3255,8 @@ ath10k_mac_tx_h_get_txmode(struct ath10k *ar,
if (ar->htt.target_version_major < 3 &&
(ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) &&
!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
+ ar->running_fw->fw_file.fw_features) &&
+ !test_bit(ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR,
ar->running_fw->fw_file.fw_features))
return ATH10K_HW_TXRX_MGMT;
--
1.7.9.5
Re: [PATCH] nl80211: Fix unfiltered GET_INTERFACE dumps
On Thu, 2016-08-25 at 15:44 -0500, Denis Kenzior wrote: > dump_wiphy_parse only assigns filter_wiphy if one of the supported > NL80211 attributes is present. So for unfiltered dumps, filter_wiphy > was always initialized to 0, and only interface 0 was dumped. > > This was introduced in commit > 2d75da13fbb957e955d212555b91101cef36f0ce. > > Reported-by: Arend Van Spriel > Signed-off-by: Denis Kenzior > Thanks guys, I've squashed this (and moved it into the initializer we already had.) johannes
Re: [PATCH] cfg80211: Add support for user configurable beacon data rate
On Wed, 2016-08-24 at 12:30 +, Undekari, Sunil Dutt wrote: > > It also doesn't check that you specified exactly one rate, but it's > > not clear how else this would work? > I can think of the following options here . > 1. Consider these rates as only the preference ( in order ) to the > host driver , but the User space would have no way of knowing what > the driver has selected. > 2. Limit this beacon rate to only one . cfg80211 to verify that there > is exactly one rate to be specified. > > Is option 2 a viable option ? > Yeah, I think option 1 doesn't make much sense. johannes
Re: [PATCH v2] rt2x00: add support for mac addr from device tree
On Fri, Aug 26, 2016 at 09:16:53AM +0200, Mathias Kresin wrote: > On some devices the EEPROMs of Ralink Wi-Fi chips have a default Ralink > MAC address set (RT3062F: 00:0C:43:30:62:00, RT3060F: > 00:0C:43:30:60:00). Using multiple of these devices in the same network > can cause nasty issues. > > Allow to override the MAC in the EEPROM with (a known good) one set in > the device tree to bypass the issue. > > Signed-off-by: Mathias Kresin Acked-by: Stanislaw Gruszka
Re: [Make-wifi-fast] [PATCH v2] mac80211: Move crypto IV generation to after TXQ dequeue.
On Mon, 2016-08-22 at 16:47 +0200, Toke Høiland-Jørgensen wrote: > > I suppose that could be a way to do it (i.e. have > ieee80211_tx_dequeue call all the TX hooks etc), but am not sure > whether there would be problems doing all this work in the loop > that's building aggregates (which is what would happen for ath9k at > least). I don't know, but it seems that it's worth trying. > An alternative could be to split the process up in two: An "early" > and "late" stage, where the early stage does everything that is not > sensitive to reordering and the occasional drop, and the late stage > is everything that is. Then the queueing step could happen in-between > the two stages, and the non-queueing path could just call both stages > at once. In effect, this would just make the current work-arounds be > more explicit in the structure, rather than being marked as > exceptions. I'm not sure that works the way you think it does. What you did works for fast-xmit, but *only* because that doesn't do software crypto. If, for some reason, the TXQ stuff combines with software crypto, which doesn't seem impossible (ath9k even has a module parameter, iirc), then you have no way for this to work. > > Now, it's unlikely to be that simple - fragmentation, for example, > > might mess this up. > > > > Overall though, I'm definitely wondering if it should be this way, > > since all the special cases just add complexity. > > I agree that the work-arounds are iffy, but I do also think it's > important to keep in mind that we are improving latency by orders of > magnitude here. A few special cases is worth it to achieve that, IMO. > And then iterating towards a design that don't need them, of course > :) I don't really agree, I'm not going to treat this unlike any other feature, which gets merged when it's ready for that. Right now, your code here obviously isn't, since it doesn't even address the cases that ath9k could run into, so either ath9k shouldn't use this mac80211 feature, or the mac80211 feature needs to be fixed before ath9k can use it. I have no problems with documenting that the TXQ stuff can only be used with full hardware crypto, but then we should add some checks and warnings in mac80211 to ensure that, i.e. not allow software keys when TXQ stuff is used, nor allow keys with mac80211 PN assignment, etc. Even QoS-seqno assignment will be broken btw, so you do need a bunch more offloads to make this work. johannes
Re: [Make-wifi-fast] [PATCH v2] mac80211: Move crypto IV generation to after TXQ dequeue.
Johannes Berg writes: > On Mon, 2016-08-22 at 16:47 +0200, Toke Høiland-Jørgensen wrote: >> >> I suppose that could be a way to do it (i.e. have >> ieee80211_tx_dequeue call all the TX hooks etc), but am not sure >> whether there would be problems doing all this work in the loop >> that's building aggregates (which is what would happen for ath9k at >> least). > > I don't know, but it seems that it's worth trying. > >> An alternative could be to split the process up in two: An "early" >> and "late" stage, where the early stage does everything that is not >> sensitive to reordering and the occasional drop, and the late stage >> is everything that is. Then the queueing step could happen in-between >> the two stages, and the non-queueing path could just call both stages >> at once. In effect, this would just make the current work-arounds be >> more explicit in the structure, rather than being marked as >> exceptions. > > I'm not sure that works the way you think it does. > > What you did works for fast-xmit, but *only* because that doesn't do > software crypto. If, for some reason, the TXQ stuff combines with > software crypto, which doesn't seem impossible (ath9k even has a module > parameter, iirc), then you have no way for this to work. Yeah, I realised that when I started reviewing the slow path (sorry for not realising that straight away). The v3 takes the "split handlers" approach for this reason. That saved having to deal with fragmentation on TXQ dequeue, and it means that some of the processing can be done before queueing (such as GSO splitting; having packets be as small as possible before applying FQ to them is a good thing if we want to realise the full potential). It seems there are still some bugs to work out with that patch, but I'd be grateful if you could glance at it and comment on whether you think this is a viable way forward (provided we can work out all the bugs, of course). >> > Now, it's unlikely to be that simple - fragmentation, for example, >> > might mess this up. >> > >> > Overall though, I'm definitely wondering if it should be this way, >> > since all the special cases just add complexity. >> >> I agree that the work-arounds are iffy, but I do also think it's >> important to keep in mind that we are improving latency by orders of >> magnitude here. A few special cases is worth it to achieve that, IMO. >> And then iterating towards a design that don't need them, of course >> :) > > I don't really agree, I'm not going to treat this unlike any other > feature, which gets merged when it's ready for that. > > Right now, your code here obviously isn't, since it doesn't even > address the cases that ath9k could run into, so either ath9k shouldn't > use this mac80211 feature, or the mac80211 feature needs to be fixed > before ath9k can use it. Yeah, I agree now that I've looked at it some more :) > I have no problems with documenting that the TXQ stuff can only be > used with full hardware crypto, but then we should add some checks and > warnings in mac80211 to ensure that, i.e. not allow software keys when > TXQ stuff is used, nor allow keys with mac80211 PN assignment, etc. I'd much rather fix things so it works in all cases. My patch to ath9k to use this stuff completely removes the old TX path, and things like the airtime fairness scheduler needs the intermediate queues to work. -Toke
[PATCH v3] ath10k: implement NAPI support
Add NAPI support for rx and tx completion. NAPI poll is scheduled
from interrupt handler. The design is as below
- on interrupt
- schedule napi and mask interrupts
- on poll
- process all pipes (no actual Tx/Rx)
- process Rx within budget
- if quota exceeds budget reschedule napi poll by returning budget
- process Tx completions and update budget if necessary
- process Tx fetch indications (pull-push)
- push any other pending Tx (if possible)
- before resched or napi completion replenish htt rx ring buffer
- if work done < budget, complete napi poll and unmask interrupts
This change also get rid of two tasklets (intr_tq and txrx_compl_task).
Measured peak throughput with NAPI on IPQ4019 platform in controlled
environment. No noticeable reduction in throughput is seen and also
observed improvements in CPU usage. Approx. 15% CPU usage got reduced
in UDP uplink case.
DL: AP DUT Tx
UL: AP DUT Rx
IPQ4019 (avg. cpu usage %)
TOT +NAPI
=== =
TCP DL 644 Mbps (42%)645 Mbps (36%)
TCP UL 673 Mbps (30%)675 Mbps (26%)
UDP DL 682 Mbps (49%)680 Mbps (49%)
UDP UL 720 Mbps (28%)717 Mbps (11%)
Signed-off-by: Rajkumar Manoharan
---
v2: rebased change
v3: napi_synchronize and napi_disable should be called on deinit. Otherwise
it is causing invalid memory access. Thanks to Kalle for reporting this
issue.
drivers/net/wireless/ath/ath10k/ahb.c| 10 +-
drivers/net/wireless/ath/ath10k/core.c | 2 +
drivers/net/wireless/ath/ath10k/core.h | 8 ++
drivers/net/wireless/ath/ath10k/htt.h| 2 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 154 +++
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 -
drivers/net/wireless/ath/ath10k/pci.c| 71 --
drivers/net/wireless/ath/ath10k/pci.h| 6 +-
8 files changed, 159 insertions(+), 96 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ahb.c
b/drivers/net/wireless/ath/ath10k/ahb.c
index acec16b9cf49..83ecfb6d1a36 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -462,13 +462,13 @@ static void ath10k_ahb_halt_chip(struct ath10k *ar)
static irqreturn_t ath10k_ahb_interrupt_handler(int irq, void *arg)
{
struct ath10k *ar = arg;
- struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
if (!ath10k_pci_irq_pending(ar))
return IRQ_NONE;
ath10k_pci_disable_and_clear_legacy_irq(ar);
- tasklet_schedule(&ar_pci->intr_tq);
+ ath10k_pci_irq_msi_fw_mask(ar);
+ napi_schedule(&ar->napi);
return IRQ_HANDLED;
}
@@ -717,6 +717,9 @@ static void ath10k_ahb_hif_stop(struct ath10k *ar)
synchronize_irq(ar_ahb->irq);
ath10k_pci_flush(ar);
+
+ napi_synchronize(&ar->napi);
+ napi_disable(&ar->napi);
}
static int ath10k_ahb_hif_power_up(struct ath10k *ar)
@@ -748,6 +751,7 @@ static int ath10k_ahb_hif_power_up(struct ath10k *ar)
ath10k_err(ar, "could not wake up target CPU: %d\n", ret);
goto err_ce_deinit;
}
+ napi_enable(&ar->napi);
return 0;
@@ -831,7 +835,7 @@ static int ath10k_ahb_probe(struct platform_device *pdev)
goto err_resource_deinit;
}
- ath10k_pci_init_irq_tasklets(ar);
+ ath10k_pci_init_napi(ar);
ret = ath10k_ahb_request_irq_legacy(ar);
if (ret)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index e88982921aa3..0ca58cf0ffea 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2249,6 +2249,8 @@ struct ath10k *ath10k_core_create(size_t priv_size,
struct device *dev,
INIT_WORK(&ar->register_work, ath10k_core_register_work);
INIT_WORK(&ar->restart_work, ath10k_core_restart);
+ init_dummy_netdev(&ar->napi_dev);
+
ret = ath10k_debug_create(ar);
if (ret)
goto err_free_aux_wq;
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 30ae5bf81611..f36c2b274ee5 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -65,6 +65,10 @@
#define ATH10K_KEEPALIVE_MAX_IDLE 3895
#define ATH10K_KEEPALIVE_MAX_UNRESPONSIVE 3900
+/* NAPI poll budget */
+#define ATH10K_NAPI_BUDGET 64
+#define ATH10K_NAPI_QUOTA_LIMIT 60
+
struct ath10k;
enum ath10k_bus {
@@ -936,6 +940,10 @@ struct ath10k {
struct ath10k_thermal thermal;
struct ath10k_wow wow;
+ /* NAPI */
+ struct net_device napi_dev;
+ struct napi_struct napi;
+
/* must be last */
u8 drv_priv[0] __aligned(sizeof(void *));
};
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 430a83e142aa..98c14247021b 100644
--- a/drivers/net/wireless/ath/at
Re: [PATCH v3] ath10k: implement NAPI support
I'm always rather big on people testing latency under load, and napi tends to add some.
Re: [PATCH v3] ath10k: implement NAPI support
On Fri, 2016-08-26 at 03:48 -0700, Dave Taht wrote: > I'm always rather big on people testing latency under load, and napi > tends to add some. That's a completely useless comment. Obviously, everybody uses NAPI; it's necessary for system load and thus performance, and lets drivers take advantage of TCP merging to reduce ACKs, which is tremendously helpful (over wifi in particular.) Please stop making such drive-by comments that focus only on the single thing you find important above all; not all people can care only about that single thing, and unconstructively reiterating it over and over doesn't help. Thanks, johannes
Re: [PATCH v3] ath10k: implement NAPI support
On Fri, Aug 26, 2016 at 4:12 AM, Johannes Berg wrote: > On Fri, 2016-08-26 at 03:48 -0700, Dave Taht wrote: >> I'm always rather big on people testing latency under load, and napi >> tends to add some. > > That's a completely useless comment. > > Obviously, everybody uses NAPI; it's necessary for system load and thus > performance, and lets drivers take advantage of TCP merging to reduce > ACKs, which is tremendously helpful (over wifi in particular.) > > Please stop making such drive-by comments that focus only on the single > thing you find important above all; not all people can care only about > that single thing, and unconstructively reiterating it over and over > doesn't help. Well, I apologize for being testy. It is I spent a lot of time testing michal's patchset for the ath10k back in may, and I *will* go and retest ath10k, when these patches land. My principal concern with using napi is at lower rates than the maxes typically reported in a patchset. But it would be nice if people always did test for latency under load when making improvements, before getting to me, and despite having helped make a very comprehensive test suite available (flent) that tests all sorts of things for wifi, getting people to actually use it to see real problems, (in addition to latency under load!) while their fingers are still hot in the codebase, and track/plot their results, remains an ongoing issue across the entire industry. http://blog.cerowrt.org/post/fq_codel_on_ath10k/ There are many other problems in wifi, of course, that could use engineering mental internalization, like airtime fairness, and the mis-behavior of the hardware queues, http://blog.cerowrt.org/post/cs5_lockout/ wifi channel scans http://blog.cerowrt.org/post/disabling_channel_scans/ and so on. I have a ton more datasets and blog entries left to write up from the ath9k work thus far which point to some other issues (minstrel, aggregation, retries) > Thanks, > johannes -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org
Re: [PATCH v3] ath10k: implement NAPI support
On 2016-08-26 17:19, Dave Taht wrote: On Fri, Aug 26, 2016 at 4:12 AM, Johannes Berg wrote: On Fri, 2016-08-26 at 03:48 -0700, Dave Taht wrote: I'm always rather big on people testing latency under load, and napi tends to add some. That's a completely useless comment. Obviously, everybody uses NAPI; it's necessary for system load and thus performance, and lets drivers take advantage of TCP merging to reduce ACKs, which is tremendously helpful (over wifi in particular.) Please stop making such drive-by comments that focus only on the single thing you find important above all; not all people can care only about that single thing, and unconstructively reiterating it over and over doesn't help. Well, I apologize for being testy. It is I spent a lot of time testing michal's patchset for the ath10k back in may, and I *will* go and retest ath10k, when these patches land. My principal concern with using napi is at lower rates than the maxes typically reported in a patchset. You are always welcome to validate this change and share your feedback. But it would be nice if people always did test for latency under load when making improvements, before getting to me, and despite having helped make a very comprehensive test suite available (flent) that tests all sorts of things for wifi, getting people to actually use it to see real problems, (in addition to latency under load!) while their fingers are still hot in the codebase, and track/plot their results, remains an ongoing issue across the entire industry. http://blog.cerowrt.org/post/fq_codel_on_ath10k/ As you know, NAPI is designed to improve performance of high speed n/w devices. From LWN: "NAPI is a proven (www.cyberus.ca/~hadi/usenix-paper.tgz) technique to improve network performance on Linux." Even most of Gig-speed network drivers were already migrated to NAPI. Tasklets are heavy CPU consumers and it will impact performance of other low priority tasks. The article[1] explains the problems of tasklet. From my observations, average CPU usage got reduced by 10% under heavy data traffic against same peak throughput. I validated this change on both IPQ4019 platform (Quad-Core ARM Cortex A7 processor) and AP135 platform (uni-core MIPS 720 MHz processor). I did not observe any regression. There are many other problems in wifi, of course, that could use engineering mental internalization, like airtime fairness, and the mis-behavior of the hardware queues, http://blog.cerowrt.org/post/cs5_lockout/ wifi channel scans http://blog.cerowrt.org/post/disabling_channel_scans/ and so on. I have a ton more datasets and blog entries left to write up from the ath9k work thus far which point to some other issues (minstrel, aggregation, retries) your data are really impressive. Once again, feel free to validate this change and share your inputs. [1] http://lwn.net/Articles/239633/ -Rajkumar
[PATCH] ath10k: fix spelling mistake "montior" -> "monitor"
From: Colin Ian King Trivial fix to spelling mistake in ath10k_warn message. Signed-off-by: Colin Ian King --- drivers/net/wireless/ath/ath10k/mac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 0bbd0a0..841f288 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -5186,7 +5186,7 @@ static void ath10k_configure_filter(struct ieee80211_hw *hw, ret = ath10k_monitor_recalc(ar); if (ret) - ath10k_warn(ar, "failed to recalc montior: %d\n", ret); + ath10k_warn(ar, "failed to recalc monitor: %d\n", ret); mutex_unlock(&ar->conf_mutex); } -- 2.9.3
mac80211_hwsim: handling RSSI
Hi, I am developing a wireless network emulator (https://github.com/intrig-unicamp/mininet-wifi) and I was wondering what is the best way to change the RSSI information provided by mac80211_hwsim. I am able to calculate the RSSI with my emulator, but the RSSI is not updated by mac80211_hwsim, of course. Do I have to make changes in nl80211? Thank you in advance, Ramon Fontes
[PATCH] rtlwifi/rtl8192de: Fix print format string
%ul was likely meant as %lu to print an unsigned long, not an unsigned with a letter l at the end. But in fact the value printed is u32 anyway, so just drop the l completely. Signed-off-by: Oleg Drokin --- drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c index d334d2a..2a4810d 100644 --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c @@ -588,7 +588,7 @@ static bool _rtl92d_phy_config_bb_with_headerfile(struct ieee80211_hw *hw, * setting. */ udelay(1); RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE, -"The Rtl819XAGCTAB_Array_Table[0] is %ul Rtl819XPHY_REGArray[1] is %ul\n", +"The Rtl819XAGCTAB_Array_Table[0] is %u Rtl819XPHY_REGArray[1] is %u\n", agctab_array_table[i], agctab_array_table[i + 1]); } @@ -604,7 +604,7 @@ static bool _rtl92d_phy_config_bb_with_headerfile(struct ieee80211_hw *hw, * setting. */ udelay(1); RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE, -"The Rtl819XAGCTAB_Array_Table[0] is %ul Rtl819XPHY_REGArray[1] is %ul\n", +"The Rtl819XAGCTAB_Array_Table[0] is %u Rtl819XPHY_REGArray[1] is %u\n", agctab_array_table[i], agctab_array_table[i + 1]); } @@ -620,7 +620,7 @@ static bool _rtl92d_phy_config_bb_with_headerfile(struct ieee80211_hw *hw, * setting. */ udelay(1); RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE, -"The Rtl819XAGCTAB_5GArray_Table[0] is %ul Rtl819XPHY_REGArray[1] is %ul\n", +"The Rtl819XAGCTAB_5GArray_Table[0] is %u Rtl819XPHY_REGArray[1] is %u\n", agctab_5garray_table[i], agctab_5garray_table[i + 1]); } -- 2.7.4
[PATCH] fix:brcmfmac: add missing header dependencies
We get 1 warning when biuld kernel with W=1:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c:23:6: warning: no
previous prototype for '__brcmf_err' [-Wmissing-
prototypes]
In fact, this function is declared in brcmfmac/debuge.h, so this patch
add missing header dependencies
Signed-off-by: Baoyou Xie
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
index a10f35c..fe67559 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
@@ -19,6 +19,7 @@
#ifndef __CHECKER__
#define CREATE_TRACE_POINTS
#include "tracepoint.h"
+#include "debug.h"
void __brcmf_err(const char *func, const char *fmt, ...)
{
--
2.7.4
[PATCH v2] fix:brcmfmac: add missing header dependencies
We get 1 warning when biuld kernel with W=1:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c:23:6: warning: no
previous prototype for '__brcmf_err' [-Wmissing-
prototypes]
In fact, this function is declared in brcmfmac/debug.h, so this patch
add missing header dependencies
Signed-off-by: Baoyou Xie
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
index a10f35c..fe67559 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
@@ -19,6 +19,7 @@
#ifndef __CHECKER__
#define CREATE_TRACE_POINTS
#include "tracepoint.h"
+#include "debug.h"
void __brcmf_err(const char *func, const char *fmt, ...)
{
--
2.7.4
