Re: cw1200: use msecs_to_jiffies for conversion
This is only an API consolidation to make things more readable. Instances of HZ / CONST are replaced by appropriate msecs_to_jiffies(). Signed-off-by: Nicholas Mc Guire hof...@osadl.org 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 3/4] bcma: support bringing up bus hosted on PCIe Gen 2
Rafał Miłecki zaj...@gmail.com writes:
+void bcma_core_pcie2_up(struct bcma_drv_pcie2 *pcie2)
+{
+ struct bcma_bus *bus = pcie2-core-bus;
+ struct pci_dev *dev = bus-host_pci;
+
+ pcie_capability_clear_and_set_word(dev, PCI_EXP_DEVCTL,
+PCI_EXP_DEVCTL_READRQ,
+pcie2-reqsize);
Use pcie_set_readrq() if it is needed.
What do you mean by if needed? Is there anything wrong?
So what's the conclusion? Can I apply these?
--
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] orinoco: orinoco_plx use msecs_to_jiffies for conversion
This is only an API consolidation and should make things more readable it replaces var * HZ / 1000 by msecs_to_jiffies(var). Signed-off-by: Nicholas Mc Guire hof...@osadl.org Thanks, 3 patches applied to wireless-drivers-next.git: ab458cc85fa2 orinoco: orinoco_plx use msecs_to_jiffies for conversion 3427da4597ae orinoco: orinoco_pci use msecs_to_jiffies for conversion c1f1f6663b3c orinoco: orinoco_tmd use msecs_to_jiffies for conversion 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
[PATCH] cfg80211: add debugfs VHT80 allow map
Here is a output of this debugfs entry
root@OpenWrt:/# cat /sys/kernel/debug/ieee80211/phy0/vht80allow_map
2412 VHT80 N
2417 VHT80 N
2422 VHT80 N
2427 VHT80 N
2432 VHT80 N
2437 VHT80 N
2442 VHT80 N
2447 VHT80 N
2452 VHT80 N
2457 VHT80 N
2462 VHT80 N
2467 Disabled
2472 Disabled
2484 Disabled
5180 VHT80 Y
5200 VHT80 Y
5220 VHT80 Y
5240 VHT80 Y
5260 VHT80 Y
5280 VHT80 Y
5300 VHT80 Y
5320 VHT80 Y
5500 VHT80 Y
5520 VHT80 Y
5540 VHT80 Y
5560 VHT80 Y
5580 VHT80 Y
5600 Disabled
5620 Disabled
5640 Disabled
5660 VHT80 Y
5680 VHT80 Y
5700 VHT80 Y
5745 VHT80 Y
5765 VHT80 Y
5785 VHT80 Y
5805 VHT80 Y
5825 VHT80 Y
Signed-off-by: Ashok Raj Nagarajan arnag...@qti.qualcomm.com
---
net/wireless/debugfs.c | 61
1 file changed, 61 insertions(+)
diff --git a/net/wireless/debugfs.c b/net/wireless/debugfs.c
index 4541577..0349dcd 100644
--- a/net/wireless/debugfs.c
+++ b/net/wireless/debugfs.c
@@ -102,6 +102,66 @@ static const struct file_operations ht40allow_map_ops = {
.llseek = default_llseek,
};
+static int vht80_print_chan(struct ieee80211_channel *chan,
+ char *buf, int buf_size, int offset)
+{
+ if (WARN_ON(offset buf_size))
+ return 0;
+
+ if (chan-flags IEEE80211_CHAN_DISABLED)
+ return scnprintf(buf + offset,
+buf_size - offset,
+%d Disabled\n,
+chan-center_freq);
+
+ return scnprintf(buf + offset,
+buf_size - offset,
+%d VHT80 %c\n,
+chan-center_freq,
+(chan-flags IEEE80211_CHAN_NO_80MHZ) ?
+ 'N' : 'Y');
+}
+
+static ssize_t vht80allow_map_read(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct wiphy *wiphy = file-private_data;
+ char *buf;
+ unsigned int offset = 0, buf_size = PAGE_SIZE, i, r;
+ enum ieee80211_band band;
+ struct ieee80211_supported_band *sband;
+
+ buf = kzalloc(buf_size, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ rtnl_lock();
+
+ for (band = 0; band IEEE80211_NUM_BANDS; band++) {
+ sband = wiphy-bands[band];
+ if (!sband)
+ continue;
+ for (i = 0; i sband-n_channels; i++)
+ offset += vht80_print_chan(sband-channels[i],
+ buf, buf_size, offset);
+ }
+
+ rtnl_unlock();
+
+ r = simple_read_from_buffer(user_buf, count, ppos, buf, offset);
+
+ kfree(buf);
+
+ return r;
+}
+
+static const struct file_operations vht80allow_map_ops = {
+ .read = vht80allow_map_read,
+ .open = simple_open,
+ .llseek = default_llseek,
+};
+
#define DEBUGFS_ADD(name) \
debugfs_create_file(#name, S_IRUGO, phyd, rdev-wiphy, name## _ops);
@@ -114,4 +174,5 @@ void cfg80211_debugfs_rdev_add(struct
cfg80211_registered_device *rdev)
DEBUGFS_ADD(short_retry_limit);
DEBUGFS_ADD(long_retry_limit);
DEBUGFS_ADD(ht40allow_map);
+ DEBUGFS_ADD(vht80allow_map);
}
--
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: [RESEND, 1/2] rtlwifi: rtl8192ee: Fix handling of new style descriptors
From: Troy Tan troy_...@realsil.com.cn The hardware and firmware for the RTL8192EE utilize a FIFO list of descriptors. There were some problems with the initial implementation. The worst of these failed to detect that the FIFO was becoming full, which led to the device needing to be power cycled. As this condition is not relevant to most of the devices supported by rtlwifi, a callback routine was added to detect this situation. This patch implements the necessary changes in the pci handler, and the linkage into the appropriate rtl8192ee routine. Signed-off-by: Troy Tan troy_...@realsil.com.cn Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Stable sta...@vger.kernel.org [V3.18] Thanks, 2 patches applied to wireless-drivers-next.git: d0311314d002 rtlwifi: rtl8192ee: Fix handling of new style descriptors 6d4beca37752 rtlwifi: rtl8192ee: Fix problems with calculating free space in FIFO 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: rtl8192ee (Thinkpad T440s)
On 2015-02-05 22:11, Larry Finger wrote: On 02/05/2015 12:56 AM, Ken D'Ambrosio wrote: Did the update to the troy branch of the rtlwifi_new repo fix the problem? Sadly, no. Exact same errors. So I looked at your previous e-mail, which I've pasted (and commented about), below: Do any ACPI warning messages appear in the early boot log? I found some mention of a module named thinkpad_acpi. Is it loaded? There's a bunch of ACPI stuff, some of which seems related: [8.548934] thinkpad_acpi: Unsupported brightness interface, please contact ibm-acpi-de...@lists.sourceforge.net [8.549028] thinkpad_acpi: radio switch found; radios are enabled [8.549135] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver [8.549137] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... [8.550374] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [8.551069] thinkpad_acpi: rfkill switch tpacpi_wwan_sw: radio is unblocked The lack of an rfkill switch for WiFi might be disconcerting at first, until you read the corresponding kernel doc, /usr/src/linux/Documentation/laptops/thinkpad-acpi.txt: 0x1005 0x04FN+F5 Radio. Enables/disables the internal Bluetooth hardware and W-WAN card if left in control of the firmware. Does not affect the WLAN card. Should be used to turn on/off all radios (Bluetooth+W-WAN+WLAN), really. Additionally: hotkey_radio_sw: If the ThinkPad has a hardware radio switch, this attribute will read 0 if the switch is in the radios disabled position, and 1 if the switch is in the radios enabled position. A quick visit to /sys/devices/platform/thinkpad_acpi/hotkey_radio_sw shows it with a value of 1, so, as far as I can tell, ACPI is not blocking the WiFi radio. Sometimes this can be caused by some state left by Windows. Do you dual boot? Perish the thought. While I haven't booted Windows, neither have I blown away the partition; if you'd like me to boot into it and initialize the card, I'd be willing to give that a try. Lastly, however, is something weird that makes me think that the extreme step of using Windows may not be required: the USB WiFi I use because my internal WiFi isn't working is an RTL8188SU. If I leave both of them in when I initialize, SOMETIMES I can get the 8192EE to work -- even after I remove the 8188SU. But I haven't once gotten the 8192EE to work without the 8188SU also inserted. And I can't reproduce this functionality reliably. -Ken -- 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: rtl8192ee (Thinkpad T440s)
P.S. I'm sorry, I left this out: I only get the same errors during a manual module load. At boot time, things seem to go somewhat more smoothly -- though still fails to connect to anything. I've attached my dmesg text so you can parse it more fully. -Ken On 2015-02-06 00:57, Ken D'Ambrosio wrote: On 2015-02-05 22:11, Larry Finger wrote: On 02/05/2015 12:56 AM, Ken D'Ambrosio wrote: Did the update to the troy branch of the rtlwifi_new repo fix the problem? Sadly, no. Exact same errors. So I looked at your previous e-mail, which I've pasted (and commented about), below: Do any ACPI warning messages appear in the early boot log? I found some mention of a module named thinkpad_acpi. Is it loaded? There's a bunch of ACPI stuff, some of which seems related: [8.548934] thinkpad_acpi: Unsupported brightness interface, please contact ibm-acpi-de...@lists.sourceforge.net [8.549028] thinkpad_acpi: radio switch found; radios are enabled [8.549135] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver [8.549137] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... [8.550374] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [8.551069] thinkpad_acpi: rfkill switch tpacpi_wwan_sw: radio is unblocked The lack of an rfkill switch for WiFi might be disconcerting at first, until you read the corresponding kernel doc, /usr/src/linux/Documentation/laptops/thinkpad-acpi.txt: 0x1005 0x04FN+F5 Radio. Enables/disables the internal Bluetooth hardware and W-WAN card if left in control of the firmware. Does not affect the WLAN card. Should be used to turn on/off all radios (Bluetooth+W-WAN+WLAN), really. Additionally: hotkey_radio_sw: If the ThinkPad has a hardware radio switch, this attribute will read 0 if the switch is in the radios disabled position, and 1 if the switch is in the radios enabled position. A quick visit to /sys/devices/platform/thinkpad_acpi/hotkey_radio_sw shows it with a value of 1, so, as far as I can tell, ACPI is not blocking the WiFi radio. Sometimes this can be caused by some state left by Windows. Do you dual boot? Perish the thought. While I haven't booted Windows, neither have I blown away the partition; if you'd like me to boot into it and initialize the card, I'd be willing to give that a try. Lastly, however, is something weird that makes me think that the extreme step of using Windows may not be required: the USB WiFi I use because my internal WiFi isn't working is an RTL8188SU. If I leave both of them in when I initialize, SOMETIMES I can get the 8192EE to work -- even after I remove the 8188SU. But I haven't once gotten the 8192EE to work without the 8188SU also inserted. And I can't reproduce this functionality reliably. -Ken -- 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[0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.19.0-rc7-next-20150204 (root@minasithil) (gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6) ) #3 SMP Thu Feb 5 00:18:20 EST 2015 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.20-next root=/dev/sda7 ro [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009cfff] usable [0.00] BIOS-e820: [mem 0x0009d000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xce21dfff] usable [0.00] BIOS-e820: [mem 0xce21e000-0xdcd3efff] reserved [0.00] BIOS-e820: [mem 0xdcd3f000-0xdce7efff] ACPI NVS [0.00] BIOS-e820: [mem 0xdce7f000-0xdcefefff] ACPI data [0.00] BIOS-e820: [mem 0xdceff000-0xdf9f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfe101000-0xfe112fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved [0.00] BIOS-e820: [mem
Re: [PATCH 0/6] ath9k patches
Sujith Manoharan suj...@msujith.org writes: From: Sujith Manoharan c_man...@qca.qualcomm.com ath9k patches for -next. Sujith Manoharan (6): ath9k: Add support for more WOW patterns ath9k: Register correct WOW details with mac80211 ath9k: Fix issues with WoW enable ath9k: Program AR_WA correctly ath9k: Clear TSF2 properly ath9k: Choose correct rate for 2GHz channel Thanks, all six patches applied. -- 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: ath5k: fix spontaneus AR5312 freezes
Sometimes while CPU have some load and ath5k doing the wireless interface reset the whole WiSoC completely freezes. Set of tests shows that using atomic delay function while we wait interface reset helps to avoid such freezes. The easiest way to reproduce this issue: create a station interface, start continous scan with wpa_supplicant and load CPU by something. Or just create multiple station interfaces and put them all in continous scan. This patch partially reverts the commit 1846ac3dbec0 (ath5k: Use usleep_range where possible), which replaces initial udelay() by usleep_range(). I do not know actual source of this issue, but all looks like that HW freeze is caused by transaction on internal SoC bus, while wireless block is in reset state. Also I should note that I do not know how many chips are affected, but I did not see this issue with chips, other than AR5312. CC: Jiri Slaby jirisl...@gmail.com CC: Nick Kossifidis mickfl...@gmail.com CC: Luis R. Rodriguez mcg...@do-not-panic.com Fixes: 1846ac3dbec0 (ath5k: Use usleep_range where possible) Reported-by: Christophe Prevotaux c.prevot...@rural-networks.com Tested-by: Christophe Prevotaux c.prevot...@rural-networks.com Tested-by: Eric Bree eb...@nltinc.com Signed-off-by: Sergey Ryazanov ryazanov@gmail.com 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/2] cw1200: Delete an unnecessary check before the function call release_firmware
From: Markus Elfring elfr...@users.sourceforge.net Date: Wed, 4 Feb 2015 16:32:15 +0100 The release_firmware() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring elfr...@users.sourceforge.net Thanks, 2 patches applied to wireless-drivers-next.git: df970d39b90e cw1200: Delete an unnecessary check before the function call release_firmware ee4ddad82356 cw1200: Less function calls in cw1200_load_firmware_cw1200() after error detection 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: ath9k: Delete an unnecessary check before the function callrelay_close
From: Markus Elfring elfr...@users.sourceforge.net Date: Wed, 4 Feb 2015 18:48:28 +0100 The relay_close() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring elfr...@users.sourceforge.net 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: pull request: iwlwifi-next 2015-02-03
Grumbach, Emmanuel emmanuel.grumb...@intel.com writes: Here is probably the last pull request for 3.20. Details below. Since it is probably too late to send patches for 3.19, There are a few patches here that are tagged for stable. Please let me know if you have issues! The following changes since commit 0b83795a110248db8f8e7c289a27b3b71b0bb35a: iwlwifi: mvm: fix rx chains configuration in phy ctxt cmd (2015-01-22 22:17:22 +0200) Thanks, pulled. -- 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: Throughput regression with `tcp: refine TSO autosizing`
On Thu, 2015-02-05 at 07:46 +0100, Michal Kazior wrote: On 4 February 2015 at 22:11, Eric Dumazet eric.duma...@gmail.com wrote: Most conservative patch would be : diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c index 9c782a42665e1aaf43bfbca441631ee58da50c09..6a36317d6bb0447202dee15528130bd5e21248c4 100644 --- a/drivers/net/wireless/ath/ath10k/htt_rx.c +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c @@ -1642,6 +1642,7 @@ void ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb) break; } case HTT_T2H_MSG_TYPE_TX_COMPL_IND: + skb_orphan(skb); spin_lock_bh(htt-tx_lock); __skb_queue_tail(htt-tx_compl_q, skb); spin_unlock_bh(htt-tx_lock); I suppose you want to call skb_orphan() on actual data packets, right? This skb is just a host-firmware communication buffer. Right. I have no idea how you find the actual data packet at this stage. -- 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: Throughput regression with `tcp: refine TSO autosizing`
On Thu, 2015-02-05 at 04:57 -0800, Eric Dumazet wrote: The intention is to control the queues to the following : 1 ms of buffering, but limited to a configurable value. On a 40Gbps flow, 1ms represents 5 MB, which is insane. We do not want to queue 5 MB of traffic, this would destroy latencies for all concurrent flows. (Or would require having fq_codel or fq as packet schedulers, instead of default pfifo_fast) This is why having 1.5 ms delay between the transmit and TX completion is a problem in your case. Note that TCP stack could detect when this happens, *if* ACK where delivered before the TX completions, or when TX completion happens, we could detect that the clone of the freed packet was freed. In my test, when I did ethtool -C eth0 tx-usecs 1024 tx-frames 64, and disabling GSO, TCP stack sends a bunch of packets (a bit less than 64), blocks on tcp_limit_output_bytes. Then we receive 2 stretch ACKS after ~50 usec. TCP stack tries to push again some packets but blocks on tcp_limit_output_bytes again. 1ms later, TX completion happens, tcp_wfree() is called, and TCP stack push following ~60 packets. TCP could eventually dynamically adjust the tcp_limit_output_bytes, using a per flow dynamic value, but I would rather not add a kludge in TCP stack only to deal with a possible bug in ath10k driver. niu has a similar issue and simply had to call skb_orphan() : drivers/net/ethernet/sun/niu.c:6669:skb_orphan(skb); -- 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: Throughput regression with `tcp: refine TSO autosizing`
On 5 February 2015 at 14:19, Eric Dumazet eric.duma...@gmail.com wrote:
On Thu, 2015-02-05 at 04:57 -0800, Eric Dumazet wrote:
The intention is to control the queues to the following :
1 ms of buffering, but limited to a configurable value.
On a 40Gbps flow, 1ms represents 5 MB, which is insane.
We do not want to queue 5 MB of traffic, this would destroy latencies
for all concurrent flows. (Or would require having fq_codel or fq as
packet schedulers, instead of default pfifo_fast)
This is why having 1.5 ms delay between the transmit and TX completion
is a problem in your case.
I do get your point. But 1.5ms is really tough on Wi-Fi.
Just look at this:
; ping 192.168.1.2 -c 3
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.83 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=2.02 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=1.98 ms
; ping 192.168.1.2 -c 3 -Q 224
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.939 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.906 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.946 ms
This was run with no load so batching code in the driver itself should
have no measurable effect. The channel was near-ideal: low noise
floor, cabled rf, no other traffic.
The lower latency ping is when 802.11 QoS Voice Access Category is
used. I also get 400mbps instead of 250mbps in this case with 5 flows
(net/master).
Dealing with black box firmware blobs is a pain.
Note that TCP stack could detect when this happens, *if* ACK where
delivered before the TX completions, or when TX completion happens,
we could detect that the clone of the freed packet was freed.
In my test, when I did ethtool -C eth0 tx-usecs 1024 tx-frames 64, and
disabling GSO, TCP stack sends a bunch of packets (a bit less than 64),
blocks on tcp_limit_output_bytes.
Then we receive 2 stretch ACKS after ~50 usec.
TCP stack tries to push again some packets but blocks on
tcp_limit_output_bytes again.
1ms later, TX completion happens, tcp_wfree() is called, and TCP stack
push following ~60 packets.
TCP could eventually dynamically adjust the tcp_limit_output_bytes,
using a per flow dynamic value, but I would rather not add a kludge in
TCP stack only to deal with a possible bug in ath10k driver.
niu has a similar issue and simply had to call skb_orphan() :
drivers/net/ethernet/sun/niu.c:6669:skb_orphan(skb);
Ok. I tried calling skb_orphan() right after I submit each Tx frame
(similar to niu which does this in start_xmit):
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -564,6 +564,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct
sk_buff *msdu)
if (res)
goto err_unmap_msdu;
+ skb_orphan(msdu);
+
return 0;
err_unmap_msdu:
Now, with {net/master + ath10k GRO + the above} I get 620mbps on a
single flow (even better then before). Wow.
Does this look ok/safe as a solution to you?
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
Re: Throughput regression with `tcp: refine TSO autosizing`
On Thu, 2015-02-05 at 05:19 -0800, Eric Dumazet wrote: TCP could eventually dynamically adjust the tcp_limit_output_bytes, using a per flow dynamic value, but I would rather not add a kludge in TCP stack only to deal with a possible bug in ath10k driver. niu has a similar issue and simply had to call skb_orphan() : drivers/net/ethernet/sun/niu.c:6669:skb_orphan(skb); In your case that might be the place : diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c index 4bc51d8a14a3..cbda7a87d5a1 100644 --- a/drivers/net/wireless/ath/ath10k/htt_tx.c +++ b/drivers/net/wireless/ath/ath10k/htt_tx.c @@ -468,6 +468,7 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu) msdu_id = res; htt-pending_tx[msdu_id] = msdu; spin_unlock_bh(htt-tx_lock); + skb_orphan(msdu); prefetch_len = min(htt-prefetch_len, msdu-len); prefetch_len = roundup(prefetch_len, 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: Throughput regression with `tcp: refine TSO autosizing`
On Thu, 2015-02-05 at 09:38 +0100, Michal Kazior wrote:
On 4 February 2015 at 22:11, Eric Dumazet eric.duma...@gmail.com wrote:
I do not see how a TSO patch could hurt a flow not using TSO/GSO.
This makes no sense.
Hmm..
@@ -2018,8 +2053,8 @@ static bool tcp_write_xmit(struct sock *sk,
unsigned int mss_now, int nonagle,
* of queued bytes to ensure line rate.
* One example is wifi aggregation (802.11 AMPDU)
*/
- limit = max_t(unsigned int, sysctl_tcp_limit_output_bytes,
- sk-sk_pacing_rate 10);
+ limit = max(2 * skb-truesize, sk-sk_pacing_rate 10);
+ limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
if (atomic_read(sk-sk_wmem_alloc) limit) {
set_bit(TSQ_THROTTLED, tp-tsq_flags);
Doesn't this effectively invert how tcp_limit_output_bytes is used?
This would explain why raising the limit wasn't changing anything
anymore when you asked me do so. Only decreasing it yielded any
change.
I've added a printk to show up the new and old values. Excerpt from logs:
[ 114.782740] (4608 39126 131072 = 39126) vs (131072 39126 = 131072)
(2*truesize, pacing_rate, tcp_limit = limit) vs (tcp_limit, pacing_rate =
limit)
Reverting this patch hunk alone fixes my TCP problem. Not that I'm
saying the old logic was correct (it seems it wasn't, a limit should
be applied as min(value, max_value), right?).
Anyway the change doesn't seem to be TSO-only oriented so it would
explain the makes no sense.
The intention is to control the queues to the following :
1 ms of buffering, but limited to a configurable value.
On a 40Gbps flow, 1ms represents 5 MB, which is insane.
We do not want to queue 5 MB of traffic, this would destroy latencies
for all concurrent flows. (Or would require having fq_codel or fq as
packet schedulers, instead of default pfifo_fast)
This is why having 1.5 ms delay between the transmit and TX completion
is a problem in your case.
--
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
NetDev 0.1 final schedule and new sponsor update
Fellow netheads: New Sponsor: == We thank Intel for supporting Netdev01. Intel is well known in its tradition for supporting open source projects. http://www.intel.com/ Schedule: == The final schedule is out coded with session links. https://www.netdev01.org/schedule Registration: == https://onlineregistrations.ca/netdev01/ $100/day, or $350 for 4 days (Cdn dollars). (online reg closes Feb 12th) Please register as early as practical. Registering helps us plan properly for numbers of attendees, ensuring venue sizes and supplies are appropriate without wasting resources. Hotel discount rates deadline extended == The Westin Hotel may still have rooms for Netdev01 available. There are lots of big and small hotels in Ottawa, but they will fill up fast as Winterlude approaches, so book something soon. There may be some possibilities to billet locally, but don't leave it last minute. Make your reservations at: https://www.starwoodmeeting.com/StarGroupsWeb/res?id=1412035802key=1AC9C1F8 Sponsors: = NetDev 0.1 would like to gratefully acknowledge all our sponsors: https://netdev01.org/sponsors CENGN http://www.cengn.ca/ Google https://www.google.ca Qualcommhttps://www.qualcomm.com/ Verizon http://www.verizon.com/ Cumulus Networkshttp://cumulusnetworks.com/ Mojatatu Networks http://mojatatu.com/ --- THE Technical Conference on Linux Networking, February 14-17, 2015, Ottawa, Canada https://netdev01.org/ Contact:i...@netdev01.info Main site: https://www.netdev01.org/ Travel/hotel/weather/clothing: https://www.netdev01.org/travel RSS feed: https://netdev01.org/atom Follow us on Twitter: @netdev01 https://twitter.com/netdev01 -- 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] mac80211_hwsim: fix error handling in tx_frame_nl
Correct two problems with the error handling when using the netlink forwarding API: first, the netlink skb is never freed if nla_put() fails; and second, genlmsg_unicast() can fail if the netlink socket is full. In the latter case, the corresponding data skb is not counted as a drop and userspace programs like wmediumd will see TCP stalls due to lost packets. Signed-off-by: Bob Copeland m...@bobcopeland.com --- drivers/net/wireless/mac80211_hwsim.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c index 74f4e1c..1204853 100644 --- a/drivers/net/wireless/mac80211_hwsim.c +++ b/drivers/net/wireless/mac80211_hwsim.c @@ -947,7 +947,8 @@ static void mac80211_hwsim_tx_frame_nl(struct ieee80211_hw *hw, goto nla_put_failure; genlmsg_end(skb, msg_head); - genlmsg_unicast(init_net, skb, dst_portid); + if (genlmsg_unicast(init_net, skb, dst_portid)) + goto err_free_txskb; /* Enqueue the packet */ skb_queue_tail(data-pending, my_skb); @@ -956,6 +957,8 @@ static void mac80211_hwsim_tx_frame_nl(struct ieee80211_hw *hw, return; nla_put_failure: + nlmsg_free(skb); +err_free_txskb: printk(KERN_DEBUG mac80211_hwsim: error occurred in %s\n, __func__); ieee80211_free_txskb(hw, my_skb); data-tx_failed++; -- 2.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: Throughput regression with `tcp: refine TSO autosizing`
On Thu, 2015-02-05 at 14:44 +0100, Michal Kazior wrote: I do get your point. But 1.5ms is really tough on Wi-Fi. Just look at this: ; ping 192.168.1.2 -c 3 PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.83 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=2.02 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=1.98 ms Thats a different point. I dont care about rtt but TX completions. (usually much much lower than rtt) I can have a 4 usec delay from the moment a NIC submits a packet to the wire and I get TX completion IRQ, free the packet. Yet the pong reply can come 100 ms later. It does not mean the 4 usec delay is a problem. -- 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] brcmfmac: avoid duplicated suspend/resume operation
On 2015/2/3 21:08, Kalle Valo wrote: Fu, Zhonghui zhonghui...@linux.intel.com writes: From ff39ed4af9f1c50358fe92ec4c8eaac9db183e00 Mon Sep 17 00:00:00 2001 From: Zhonghui Fu zhonghui...@linux.intel.com Date: Mon, 26 Jan 2015 10:13:21 +0800 Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation WiFi chip has 2 SDIO functions, and PM core will trigger twice suspend/resume operations for one WiFi chip to do the same things. This patch avoid this case. Acked-by: Arend van Sprielar...@broadcom.com Signed-off-by: Zhonghui Fu zhonghui...@linux.intel.com This doesn't apply: Applying: brcmfmac: avoid duplicated suspend/resume operation Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c CONFLICT (content): Merge conflict in drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c Failed to merge in the changes. Patch failed at 0001 brcmfmac: avoid duplicated suspend/resume operation BTW, when you resend a patch please use [PATCH v2] (or v3, v4...) in the Subject field. Just see your comments, so please ignore my inquiry in last mail. I will re-base this patch again. Thanks, Zhonghui -- 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: Throughput regression with `tcp: refine TSO autosizing`
On 4 February 2015 at 22:11, Eric Dumazet eric.duma...@gmail.com wrote:
I do not see how a TSO patch could hurt a flow not using TSO/GSO.
This makes no sense.
Hmm..
@@ -2018,8 +2053,8 @@ static bool tcp_write_xmit(struct sock *sk,
unsigned int mss_now, int nonagle,
* of queued bytes to ensure line rate.
* One example is wifi aggregation (802.11 AMPDU)
*/
- limit = max_t(unsigned int, sysctl_tcp_limit_output_bytes,
- sk-sk_pacing_rate 10);
+ limit = max(2 * skb-truesize, sk-sk_pacing_rate 10);
+ limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
if (atomic_read(sk-sk_wmem_alloc) limit) {
set_bit(TSQ_THROTTLED, tp-tsq_flags);
Doesn't this effectively invert how tcp_limit_output_bytes is used?
This would explain why raising the limit wasn't changing anything
anymore when you asked me do so. Only decreasing it yielded any
change.
I've added a printk to show up the new and old values. Excerpt from logs:
[ 114.782740] (4608 39126 131072 = 39126) vs (131072 39126 = 131072)
(2*truesize, pacing_rate, tcp_limit = limit) vs (tcp_limit, pacing_rate = limit)
Reverting this patch hunk alone fixes my TCP problem. Not that I'm
saying the old logic was correct (it seems it wasn't, a limit should
be applied as min(value, max_value), right?).
Anyway the change doesn't seem to be TSO-only oriented so it would
explain the makes no sense.
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
Re: Throughput regression with `tcp: refine TSO autosizing`
On Thu, 2015-02-05 at 14:44 +0100, Michal Kazior wrote:
Ok. I tried calling skb_orphan() right after I submit each Tx frame
(similar to niu which does this in start_xmit):
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -564,6 +564,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct
sk_buff *msdu)
if (res)
goto err_unmap_msdu;
+ skb_orphan(msdu);
+
return 0;
err_unmap_msdu:
Now, with {net/master + ath10k GRO + the above} I get 620mbps on a
single flow (even better then before). Wow.
Does this look ok/safe as a solution to you?
Not at all. This basically removes backpressure.
A single UDP socket can now blast packets regardless of SO_SNDBUF
limits.
This basically remove years of work trying to fix bufferbloat.
I still do not understand why increasing tcp_limit_output_bytes is not
working for you.
--
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: Throughput regression with `tcp: refine TSO autosizing`
On Thu, 2015-02-05 at 06:41 -0800, Eric Dumazet wrote:
Not at all. This basically removes backpressure.
A single UDP socket can now blast packets regardless of SO_SNDBUF
limits.
This basically remove years of work trying to fix bufferbloat.
I still do not understand why increasing tcp_limit_output_bytes is not
working for you.
Oh well, tcp_limit_output_bytes might be ok.
In fact, the problem comes from GSO assumption. Maybe Herbert was right,
when he suggested TCP would be simpler if we enforced GSO...
When GSO is used, the thing works because 2*skb-truesize is roughly 2
ms worth of traffic.
Because you do not use GSO, and tx completions are slow, we need this :
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 65caf8b95e17..ac01b4cd0035 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2044,7 +2044,8 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int
mss_now, int nonagle,
break;
/* TCP Small Queues :
-* Control number of packets in qdisc/devices to two packets /
or ~1 ms.
+* Control number of packets in qdisc/devices to two packets /
+* or ~2 ms (sk-sk_pacing_rate 9) in case GSO is off.
* This allows for :
* - better RTT estimation and ACK scheduling
* - faster recovery
@@ -2053,7 +2054,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int
mss_now, int nonagle,
* of queued bytes to ensure line rate.
* One example is wifi aggregation (802.11 AMPDU)
*/
- limit = max(2 * skb-truesize, sk-sk_pacing_rate 10);
+ limit = max(2 * skb-truesize, sk-sk_pacing_rate 9);
limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
if (atomic_read(sk-sk_wmem_alloc) limit) {
--
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] brcmfmac: avoid duplicated suspend/resume operation
On 02/05/15 12:34, Fu, Zhonghui wrote:
What comments about the new patch? Can this new patch be accepted?
Hi Zhonghui
Last reply from Kalle was that it did not apply to his tree and
recommended to use version numbering so [PATCH V2] subject.
Thanks,
Zhonghui
On 2015/1/26 10:46, Fu, Zhonghui wrote:
From ff39ed4af9f1c50358fe92ec4c8eaac9db183e00 Mon Sep 17 00:00:00 2001
From: Zhonghui Fuzhonghui...@linux.intel.com
Date: Mon, 26 Jan 2015 10:13:21 +0800
Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
WiFi chip has 2 SDIO functions, and PM core will trigger
twice suspend/resume operations for one WiFi chip to do
the same things. This patch avoid this case.
Acked-by: Arend van Sprielar...@broadcom.com
Signed-off-by: Zhonghui Fuzhonghui...@linux.intel.com
---
And when using version info a change log here is even better. Although
admittedly I lost track which version this would be ;-)
Regards,
Arend
---
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
index 9880dae..618b545 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
@@ -1139,11 +1139,17 @@ void brcmf_sdio_wowl_config(struct device *dev, bool
enabled)
static int brcmf_ops_sdio_suspend(struct device *dev)
{
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
- struct brcmf_sdio_dev *sdiodev = bus_if-bus_priv.sdio;
+ struct brcmf_sdio_dev *sdiodev;
mmc_pm_flag_t sdio_flags;
+ struct sdio_func *func = dev_to_sdio_func(dev);
brcmf_dbg(SDIO, Enter\n);
+ if (func-num == 2)
+ return 0;
+
+ sdiodev = bus_if-bus_priv.sdio;
+
atomic_set(sdiodev-suspend, true);
if (sdiodev-wowl_enabled) {
@@ -1164,9 +1170,16 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
static int brcmf_ops_sdio_resume(struct device *dev)
{
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
- struct brcmf_sdio_dev *sdiodev = bus_if-bus_priv.sdio;
+ struct brcmf_sdio_dev *sdiodev;
+ struct sdio_func *func = dev_to_sdio_func(dev);
brcmf_dbg(SDIO, Enter\n);
+
+ if (func-num == 2)
+ return 0;
+
+ sdiodev = bus_if-bus_priv.sdio;
+
if (sdiodev-pdata sdiodev-pdata-oob_irq_supported)
disable_irq_wake(sdiodev-pdata-oob_irq_nr);
brcmf_sdio_wd_timer(sdiodev-bus, BRCMF_WD_POLL_MS);
-- 1.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
Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
What comments about the new patch? Can this new patch be accepted?
Thanks,
Zhonghui
On 2015/1/26 10:46, Fu, Zhonghui wrote:
From ff39ed4af9f1c50358fe92ec4c8eaac9db183e00 Mon Sep 17 00:00:00 2001
From: Zhonghui Fu zhonghui...@linux.intel.com
Date: Mon, 26 Jan 2015 10:13:21 +0800
Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
WiFi chip has 2 SDIO functions, and PM core will trigger
twice suspend/resume operations for one WiFi chip to do
the same things. This patch avoid this case.
Acked-by: Arend van Sprielar...@broadcom.com
Signed-off-by: Zhonghui Fu zhonghui...@linux.intel.com
---
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
index 9880dae..618b545 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
@@ -1139,11 +1139,17 @@ void brcmf_sdio_wowl_config(struct device *dev, bool
enabled)
static int brcmf_ops_sdio_suspend(struct device *dev)
{
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
- struct brcmf_sdio_dev *sdiodev = bus_if-bus_priv.sdio;
+ struct brcmf_sdio_dev *sdiodev;
mmc_pm_flag_t sdio_flags;
+ struct sdio_func *func = dev_to_sdio_func(dev);
brcmf_dbg(SDIO, Enter\n);
+ if (func-num == 2)
+ return 0;
+
+ sdiodev = bus_if-bus_priv.sdio;
+
atomic_set(sdiodev-suspend, true);
if (sdiodev-wowl_enabled) {
@@ -1164,9 +1170,16 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
static int brcmf_ops_sdio_resume(struct device *dev)
{
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
- struct brcmf_sdio_dev *sdiodev = bus_if-bus_priv.sdio;
+ struct brcmf_sdio_dev *sdiodev;
+ struct sdio_func *func = dev_to_sdio_func(dev);
brcmf_dbg(SDIO, Enter\n);
+
+ if (func-num == 2)
+ return 0;
+
+ sdiodev = bus_if-bus_priv.sdio;
+
if (sdiodev-pdata sdiodev-pdata-oob_irq_supported)
disable_irq_wake(sdiodev-pdata-oob_irq_nr);
brcmf_sdio_wd_timer(sdiodev-bus, BRCMF_WD_POLL_MS);
-- 1.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
Re: [PATCH 0/4] ath10k: implement fw stats for wmi-tlv
On 4 February 2015 at 09:49, Kalle Valo kv...@qca.qualcomm.com wrote: Michal Kazior michal.kaz...@tieto.com writes: There are some slight differences in fw stats (sic) in wmi-tlv. Firmware has changed the querying scheme and no longer requires the ping-pong to get all stats. The patchset doesn't change this behaviour so with wmi-tlv it's possible to see the following warnings when reading fw stats: ath10k_pci :00:06.0: received unsolicited stats update event The logic in ath10k still produces correct results so this is harmless. I wonder how to deal with this in a sane way. An `if (op_ver == WMI_TLV)` is a little bad but having a new ar-fw_feature flag just for a debug facility like this is a bit silly. Or we can just drop the warning and leave a comment. Ideas? I think we could just remove the warning. Michal Kazior (4): ath10k: add vdev stats processing ath10k: change request stats command prototype ath10k: add more wmi fw stat defines ath10k: implement fw stats for wmi-tlv There was a conflict in patch 2 but 3-way merge solved it automatically. Please check the result in the pending branch. Looks good, thanks! 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
Re: rtl8192ee (Thinkpad T440s)
On 02/05/2015 12:56 AM, Ken D'Ambrosio wrote: Did the update to the troy branch of the rtlwifi_new repo fix the problem? 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: [PATCH] ath10k: add TxBF support
On 4 February 2015 at 09:55, Kalle Valo kv...@qca.qualcomm.com wrote: Michal Kazior michal.kaz...@tieto.com writes: If firmware advertises support for TxBF then the driver has to instruct the firmware accordingly during runtime. Without this patch connecting to an AP with beamformer support would yield abysmal Rx performance. This has been tested with wmi-tlv and qca6174 while acting as a STA beamformee only. Signed-off-by: Michal Kazior michal.kaz...@tieto.com There was a trivial conflict in ath10k_bss_disassoc(), please check my conflict resolution in the pending branch. Looks good, thanks! 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
Re: Throughput regression with `tcp: refine TSO autosizing`
On Fri, Feb 6, 2015 at 2:44 AM, Michal Kazior michal.kaz...@tieto.com wrote:
On 5 February 2015 at 14:19, Eric Dumazet eric.duma...@gmail.com wrote:
On Thu, 2015-02-05 at 04:57 -0800, Eric Dumazet wrote:
The intention is to control the queues to the following :
1 ms of buffering, but limited to a configurable value.
On a 40Gbps flow, 1ms represents 5 MB, which is insane.
We do not want to queue 5 MB of traffic, this would destroy latencies
for all concurrent flows. (Or would require having fq_codel or fq as
packet schedulers, instead of default pfifo_fast)
This is why having 1.5 ms delay between the transmit and TX completion
is a problem in your case.
I do get your point. But 1.5ms is really tough on Wi-Fi.
Just look at this:
; ping 192.168.1.2 -c 3
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.83 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=2.02 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=1.98 ms
; ping 192.168.1.2 -c 3 -Q 224
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.939 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.906 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.946 ms
This was run with no load so batching code in the driver itself should
have no measurable effect. The channel was near-ideal: low noise
floor, cabled rf, no other traffic.
The lower latency ping is when 802.11 QoS Voice Access Category is
used. I also get 400mbps instead of 250mbps in this case with 5 flows
(net/master).
The VO queue is now nearly useless in a real world environment. Whlle
it does grab the media mildly faster in some cases, on a good day with
no other competing APs, it cannot aggregate packets, and wastes TXOPS.
It is far saner to aim for better aggregate (use the VI queue if you
must try to get better media acquisition).
It is disabled in multiple products I know of.
And I really, really, really wish, that just once during this thread,
someone had bothered to try running a test
at a real world MCS rate - say MCS1, or MCS4, and measured the latency
under load of that...
or tried talking to two or more stations at the same time.
Instead of trying for 1.5Gbits in a faraday cage.
Dealing with black box firmware blobs is a pain.
+10
Note that TCP stack could detect when this happens, *if* ACK where
delivered before the TX completions, or when TX completion happens,
we could detect that the clone of the freed packet was freed.
In my test, when I did ethtool -C eth0 tx-usecs 1024 tx-frames 64, and
disabling GSO, TCP stack sends a bunch of packets (a bit less than 64),
blocks on tcp_limit_output_bytes.
Then we receive 2 stretch ACKS after ~50 usec.
TCP stack tries to push again some packets but blocks on
tcp_limit_output_bytes again.
1ms later, TX completion happens, tcp_wfree() is called, and TCP stack
push following ~60 packets.
TCP could eventually dynamically adjust the tcp_limit_output_bytes,
using a per flow dynamic value, but I would rather not add a kludge in
TCP stack only to deal with a possible bug in ath10k driver.
niu has a similar issue and simply had to call skb_orphan() :
drivers/net/ethernet/sun/niu.c:6669:skb_orphan(skb);
Ok. I tried calling skb_orphan() right after I submit each Tx frame
(similar to niu which does this in start_xmit):
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -564,6 +564,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct
sk_buff *msdu)
if (res)
goto err_unmap_msdu;
+ skb_orphan(msdu);
+
return 0;
err_unmap_msdu:
Now, with {net/master + ath10k GRO + the above} I get 620mbps on a
single flow (even better then before). Wow.
Does this look ok/safe as a solution to you?
Michał
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Täht
thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
--
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
