RE: Setting tx retry count in ath10k
Jean-Pierre TOSONI writes: > @Toke: As you can see in the patch, the value 30 was the fixed value > defined in ath9k, I kept it for compatibility only (and that's why I > wanted to make it configurable :-) Yup, I'm aware that this is the default from ath9k; doesn't make it any less wrong ;) > On another hand, Minstrel in mac80211 seems to vary retries according > to what you say, i.e. Minstrel tries to stay below a certain amount of > time, but this only applies to short/long retries. Right, haven't had time to poke into what exactly Minstrel does; have just observed that it sometimes runs really long. But for most cases it's not too bad... -Toke ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
RE: Setting tx retry count in ath10k
Hi Ben, I attached the patch. Please remind that it applies to ath9k. At the end there are 3 comments in French, translation follows: 1) " longretry gives directly the transmit count, the +1 is useless. Should rather have -1 to account for the first try" 2) " The retries just made for this frame must be added in to know If the max was overstepped" 3) " Add the 1st try (probably useless). Upstream version adds 1 to A-MPDU retries but I don't understand why. Since above I removed the +1 to fix the count, I add +1 here once per frame in case the "+1" is actually hiding a bug in the upstream version" @Toke: As you can see in the patch, the value 30 was the fixed value defined in ath9k, I kept it for compatibility only (and that's why I wanted to make it configurable :-) On another hand, Minstrel in mac80211 seems to vary retries according to what you say, i.e. Minstrel tries to stay below a certain amount of time, but this only applies to short/long retries. Jean-Pierre > -Message d'origine- > De : Toke Høiland-Jørgensen [mailto:t...@toke.dk] > Envoyé : mercredi 18 juillet 2018 18:22 > À : Ben Greear; Jean-Pierre TOSONI; SEDE; Benjamin Beichler; ath10k; > linux-wirel...@vger.kernel.org > Objet : Re: Setting tx retry count in ath10k > > Ben Greear writes: > > > On 07/18/2018 08:50 AM, Jean-Pierre TOSONI wrote: > >> Hi, > >> > >> We made retries configurable in our mac80211+ath9k system, and we ended > >> with 3 counts: > >> 1) short retry count, defaults to 4 > >> 2) long retrys count, defauts to 7 > >> 3) software retry count, defaults to 30 > >> This last one is used separately for each frame in an aggregated frame, > >> since they can be > separately acknowledged. > > > > Did you have to change code for #3, and if so, can you share the patch? > > > > I wonder also if retries should be different for different types of > > data. For instance, if someone is using UDP, maybe they don't care so > > much about lost packets and would prefer a lower retry count. Or, > > maybe IP type-of-service could be taken into account and retry frames > > different amounts based on ToS? > > For general internet traffic, a retry count of 30 is way too high; that > is up to 120 ms of HOL blocking latency. Better to just drop the packet > at that point. > > Ideally, the retry count should be dynamically calculated in units of > time (which would depend on the rate and aggregate size), and also take > queueing time into account. I've been meaning to experiment with this > for minstrel and ath9k, but haven't gotten around to it... > > -Toke a919-acksys-Add-parameter-for-software-retry.patch Description: a919-acksys-Add-parameter-for-software-retry.patch ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Setting tx retry count in ath10k
Ben Greear writes: > On 07/18/2018 08:50 AM, Jean-Pierre TOSONI wrote: >> Hi, >> >> We made retries configurable in our mac80211+ath9k system, and we ended with >> 3 counts: >> 1) short retry count, defaults to 4 >> 2) long retrys count, defauts to 7 >> 3) software retry count, defaults to 30 >> This last one is used separately for each frame in an aggregated frame, >> since they can be separately acknowledged. > > Did you have to change code for #3, and if so, can you share the patch? > > I wonder also if retries should be different for different types of > data. For instance, if someone is using UDP, maybe they don't care so > much about lost packets and would prefer a lower retry count. Or, > maybe IP type-of-service could be taken into account and retry frames > different amounts based on ToS? For general internet traffic, a retry count of 30 is way too high; that is up to 120 ms of HOL blocking latency. Better to just drop the packet at that point. Ideally, the retry count should be dynamically calculated in units of time (which would depend on the rate and aggregate size), and also take queueing time into account. I've been meaning to experiment with this for minstrel and ath9k, but haven't gotten around to it... -Toke ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Setting tx retry count in ath10k
On 07/18/2018 08:50 AM, Jean-Pierre TOSONI wrote: Hi, We made retries configurable in our mac80211+ath9k system, and we ended with 3 counts: 1) short retry count, defaults to 4 2) long retrys count, defauts to 7 3) software retry count, defaults to 30 This last one is used separately for each frame in an aggregated frame, since they can be separately acknowledged. Did you have to change code for #3, and if so, can you share the patch? I wonder also if retries should be different for different types of data. For instance, if someone is using UDP, maybe they don't care so much about lost packets and would prefer a lower retry count. Or, maybe IP type-of-service could be taken into account and retry frames different amounts based on ToS? Thanks, Ben Regards, Jean-Pierre -Message d'origine- De : linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-ow...@vger.kernel.org] De la part de Ben Greear Envoyé : mardi 17 juillet 2018 17:08 À : SEDE; Benjamin Beichler; ath10k; linux-wirel...@vger.kernel.org Objet : Re: Setting tx retry count in ath10k On 07/17/2018 12:56 AM, SEDE wrote: Hi, In the standard, 7 is the default for the short retry count, 4 is well the default for long retry count. In ath10k, there is also non_agg_sw_retry_th to control this, will this still be used? Or what is the difference with rc_num_retries? Kind regards, Sébastien. The ath10k firmware has no idea of long vs short retries, so I just used the long setting. I will investigate that non_agg_sw_retry_th as well, and I did notice my wave-1 firmware (at least) uses 15 retries for self-generated frames. But, in my case, those self-gen frames are not much used anyway since I disable firmware keep-alive. And, I need to see how the mac80211 stack handles its own retries when working with ath10k. Thanks, Ben On 2018-07-17 09:39, Benjamin Beichler wrote: Hi, Am 17.07.2018 um 02:37 schrieb Ben Greear: I spent a bit of time looking into setting the tx retry count in ath10k (wave-1 firmware). The firmware has support for setting this as a vdev parameter, and it defaults to '2', at least in my wave-1 firmware. I enabled propagating the setting from mac80211, ie: iw phy wiphy0 set retry short 2 long 2 And while debugging this, I noticed that mac80211 has a default of 4, but the ath10k firmware has a default of 2. Now, I am not sure if I should enable setting the retry count since it will change the behaviour even if users don't set anything. Maybe I'm wrong, but I have in mind, that 7 retries is the default setting of mac80211. Although 2 or even 4 seems to be pretty low for the overall retry count, so maybe the values are somehow changed in the firmware? From our experiments we know (at least for 802.11n) you need for normal operation a retry count of something between 5 - 9, but sometimes also 12 or 15 is beneficial. We use for our experimental setup mainly ath9k cards and rt28xx nics, and with them you need definitely more retries. Nonetheless, I don't think the change from 2 to 4 does really affect the behavior in a negative way (if it works as expected). Any opinions on this? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
RE: Setting tx retry count in ath10k
Hi, We made retries configurable in our mac80211+ath9k system, and we ended with 3 counts: 1) short retry count, defaults to 4 2) long retrys count, defauts to 7 3) software retry count, defaults to 30 This last one is used separately for each frame in an aggregated frame, since they can be separately acknowledged. Regards, Jean-Pierre > -Message d'origine- > De : linux-wireless-ow...@vger.kernel.org > [mailto:linux-wireless-ow...@vger.kernel.org] De la part de > Ben Greear > Envoyé : mardi 17 juillet 2018 17:08 > À : SEDE; Benjamin Beichler; ath10k; linux-wirel...@vger.kernel.org > Objet : Re: Setting tx retry count in ath10k > > > > On 07/17/2018 12:56 AM, SEDE wrote: > > Hi, > > > > In the standard, 7 is the default for the short retry count, 4 is well the > > default for long retry > count. > > > > In ath10k, there is also non_agg_sw_retry_th to control this, will this > > still be used? > > Or what is the difference with rc_num_retries? > > > > Kind regards, > > Sébastien. > > The ath10k firmware has no idea of long vs short retries, so I just used the > long setting. > > I will investigate that non_agg_sw_retry_th as well, and I did notice my > wave-1 > firmware (at least) uses 15 retries for self-generated frames. But, in my > case, > those self-gen frames are not much used anyway since I disable firmware > keep-alive. > > And, I need to see how the mac80211 stack handles its own retries when working > with ath10k. > > Thanks, > Ben > > > > > > > On 2018-07-17 09:39, Benjamin Beichler wrote: > >> Hi, > >> > >> Am 17.07.2018 um 02:37 schrieb Ben Greear: > >>> I spent a bit of time looking into setting the tx retry count in > >>> ath10k (wave-1 firmware). The firmware has support for setting this as > >>> a vdev parameter, and it defaults to '2', at least in my wave-1 firmware. > >>> > >>> I enabled propagating the setting from mac80211, ie: > >>> iw phy wiphy0 set retry short 2 long 2 > >>> > >>> And while debugging this, I noticed that mac80211 has a default of > >>> 4, but the ath10k firmware has a default of 2. Now, I am not sure > >>> if I should enable setting the retry count since it will change > >>> the behaviour even if users don't set anything. > >>> > >> Maybe I'm wrong, but I have in mind, that 7 retries is the default > >> setting of mac80211. Although 2 or even 4 seems to be pretty low for the > >> overall retry count, so maybe the values are somehow changed in the > >> firmware? From our experiments we know (at least for 802.11n) you need > >> for normal operation a retry count of something between 5 - 9, but > >> sometimes also 12 or 15 is beneficial. > >> > >> We use for our experimental setup mainly ath9k cards and rt28xx nics, > >> and with them you need definitely more retries. > >> > >> Nonetheless, I don't think the change from 2 to 4 does really affect the > >> behavior in a negative way (if it works as expected). > >> > >>> Any opinions on this? > >>> > >>> Thanks, > >>> Ben > >>> > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH] ath10k: add debugfs file warm_hw_reset
Debugfs support to do hardware warm reset with WMI command
WMI_PDEV_PARAM_PDEV_RESET for 10.4 and 10.2.4(if wmi
service is enabled in the firmware for backward compatibility).
This change is purely for debugging purpose when hardware hangs/mutes.
This hardware reset won't affect the connectivity but there will be small
pause in data traffic. Here we are doing BB/MAC level reset and hence
whenever the BB/MAC watchdog is triggered, it does a hardware_chip_reset.
So the target will be in the active state.
Below command used to warm reset the hardware.
echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/warm_hw_reset
Tested in QCA988X with firmware ver 10.2.4.70.45
Tested in QCA4019 with firmware ver 10.4-3.2.1.1-00011
Signed-off-by: Maharaja Kennadyrajan
---
drivers/net/wireless/ath/ath10k/debug.c | 49 +
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.h | 16 ++-
3 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 4926722..0baaad9 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2297,6 +2297,52 @@ static ssize_t ath10k_tpc_stats_final_read(struct file
*file,
.llseek = default_llseek,
};
+static ssize_t ath10k_write_warm_hw_reset(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath10k *ar = file->private_data;
+ int ret;
+ bool val;
+
+ if (kstrtobool_from_user(user_buf, count, &val))
+ return -EFAULT;
+
+ if (!val)
+ return -EINVAL;
+
+ mutex_lock(&ar->conf_mutex);
+
+ if (ar->state != ATH10K_STATE_ON) {
+ ret = -ENETDOWN;
+ goto exit;
+ }
+
+ if (!(test_bit(WMI_SERVICE_RESET_CHIP, ar->wmi.svc_map)))
+ ath10k_warn(ar, "wmi service for reset chip is not
available\n");
+
+ ret = ath10k_wmi_pdev_set_param(ar, ar->wmi.pdev_param->pdev_reset,
+ WMI_RST_MODE_WARM_RESET);
+
+ if (ret) {
+ ath10k_warn(ar, "failed to enable warm hw reset: %d\n", ret);
+ goto exit;
+ }
+
+ ret = count;
+
+exit:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
+}
+
+static const struct file_operations fops_warm_hw_reset = {
+ .write = ath10k_write_warm_hw_reset,
+ .open = simple_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
int ath10k_debug_create(struct ath10k *ar)
{
ar->debug.cal_data = vzalloc(ATH10K_DEBUG_CAL_DATA_LEN);
@@ -2425,6 +2471,9 @@ int ath10k_debug_register(struct ath10k *ar)
ar->debug.debugfs_phy, ar,
&fops_tpc_stats_final);
+ debugfs_create_file("warm_hw_reset", 0600, ar->debug.debugfs_phy, ar,
+ &fops_warm_hw_reset);
+
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 877249a..2fb972e 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1333,7 +1333,7 @@
.enable_per_tid_ampdu = WMI_PDEV_PARAM_UNSUPPORTED,
.cca_threshold = WMI_PDEV_PARAM_UNSUPPORTED,
.rts_fixed_rate = WMI_PDEV_PARAM_UNSUPPORTED,
- .pdev_reset = WMI_PDEV_PARAM_UNSUPPORTED,
+ .pdev_reset = WMI_10X_PDEV_PARAM_PDEV_RESET,
.wapi_mbssid_offset = WMI_PDEV_PARAM_UNSUPPORTED,
.arp_srcaddr = WMI_PDEV_PARAM_UNSUPPORTED,
.arp_dstaddr = WMI_PDEV_PARAM_UNSUPPORTED,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index d68afb6..e24d869 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -462,6 +462,7 @@ static inline char *wmi_service_name(int service_id)
SVCSTR(WMI_SERVICE_HTT_MGMT_TX_COMP_VALID_FLAGS);
SVCSTR(WMI_SERVICE_HOST_DFS_CHECK_SUPPORT);
SVCSTR(WMI_SERVICE_TPC_STATS_FINAL);
+ SVCSTR(WMI_SERVICE_RESET_CHIP);
default:
return NULL;
}
@@ -3934,7 +3935,11 @@ enum wmi_10x_pdev_param {
WMI_10X_PDEV_PARAM_REMOVE_MCAST2UCAST_BUFFER,
WMI_10X_PDEV_PARAM_PEER_STA_PS_STATECHG_ENABLE,
WMI_10X_PDEV_PARAM_RTS_FIXED_RATE,
- WMI_10X_PDEV_PARAM_CAL_PERIOD
+ WMI_10X_PDEV_PARAM_CAL_PERIOD,
+ WMI_10X_PDEV_PARAM_ATF_STRICT_SCH,
+ WMI_10X_PDEV_PARAM_ATF_SCHED_DURATION,
+ WMI_10X_PDEV_PARAM_SET_PROMISC_MODE_CMDID,
+ WMI_10X_PDEV_PARAM_PDEV_RESET
};
enum wmi_10_4_pdev_param {
@@ -6501,6 +6506,15 @@ struct wmi_force_fw_hang_cmd {
__le32 delay_ms;
} __packed;
+enum wmi_pdev_reset_mode_type {
+ WMI_RST_MODE_TX_FLUSH = 1,
+ WMI_RST_MODE_W
