EljakimHerrewijnen/Openwrt
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
3342d574be
Openwrt/package/kernel/ath10k-ct/patches/960-0011-ath10k-limit-pci-buffer-size.patch

51 lines
1.1 KiB
Diff
Raw Normal View History

ath10k-ct: switch to 5.10 Let's switch to 5.10 now that mac80211 has been updated. Runtime-tested on ipq806x (Netgear R7800). Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
2021-02-15 12:52:23 +00:00
--- a/ath10k-5.10/pci.c
+++ b/ath10k-5.10/pci.c
ath10k-ct: switch to driver version 5.8 Since we are using mac80211 5.8, let's also switch the ath10k-ct driver to the new 5.8 version. Modify patches so they patch the new ath10k-ct driver version. Adapt 164-ath10k-commit-rates-from-mac80211.patch. Drop upstreamed 205-ath10k-Add-NL80211_EXT_FEATURE_AQL-flag.patch. Drop the other options for CT_KVER from the comment, as it is incorrect and there are too many versions to sum up and maintain there. Runtime-tested on ath79 (D-Link DAP-2695-A1, TP-Link EAP245-v3). Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
2020-09-02 19:10:38 +00:00
@@ -131,7 +131,11 @@ static const struct ce_attr pci_host_ce_
kernel: ath10k-ct: provide a build variant for small RAM devices According to many bugreports [0][1][2] the default ath10k-ct kernel module is unusable on devices with just 64 MiB RAM or with 128 MiB and dual ath10k cards. The target boards boot but eventually oom-killer starts to interfere with normal operation, so the current state is effectively broken. Since the two patches in question have a performance impact (and possibly some other unexpected side-effects) a dedicated build variant is added so that users of the low RAM devices can still benefit from all the ath10k-ct advantages. According to testing [3] results, the issue can be experienced even with "a 256MB device with three radios". Measured performance impact of implementing small buffers was lowering "the maximum 5 GHz throughput on an IPQ40xx device without RPS/XPS optimizations from 494/432 Mbit/s for TCP transfers (download/upload) to 438/343 Mbit/s" The patches were apparently inspired by QSDK tweaks used by ODMs for the affected devices. [0] http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020573.html [1] https://github.com/openwrt/openwrt/pull/1077 [2] https://bugs.openwrt.org/index.php?do=details&task_id=2664 [3] https://github.com/freifunk-gluon/gluon/pull/1440#issue-195607701 Signed-off-by: Paul Fertser <fercerpav@gmail.com> [Remove double CONFIG_ATH10K-CT_LEDS entry] Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2019-12-22 18:20:57 +00:00
.flags = CE_ATTR_FLAGS,
.src_nentries = 0,
.src_sz_max = 2048,
+#ifndef CONFIG_ATH10K_SMALLBUFFERS
.dest_nentries = 512,
+#else
+ .dest_nentries = 128,
+#endif
.recv_cb = ath10k_pci_htt_htc_rx_cb,
},
ath10k-ct: switch to driver version 5.8 Since we are using mac80211 5.8, let's also switch the ath10k-ct driver to the new 5.8 version. Modify patches so they patch the new ath10k-ct driver version. Adapt 164-ath10k-commit-rates-from-mac80211.patch. Drop upstreamed 205-ath10k-Add-NL80211_EXT_FEATURE_AQL-flag.patch. Drop the other options for CT_KVER from the comment, as it is incorrect and there are too many versions to sum up and maintain there. Runtime-tested on ath79 (D-Link DAP-2695-A1, TP-Link EAP245-v3). Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
2020-09-02 19:10:38 +00:00
@@ -140,7 +144,11 @@ static const struct ce_attr pci_host_ce_
kernel: ath10k-ct: provide a build variant for small RAM devices According to many bugreports [0][1][2] the default ath10k-ct kernel module is unusable on devices with just 64 MiB RAM or with 128 MiB and dual ath10k cards. The target boards boot but eventually oom-killer starts to interfere with normal operation, so the current state is effectively broken. Since the two patches in question have a performance impact (and possibly some other unexpected side-effects) a dedicated build variant is added so that users of the low RAM devices can still benefit from all the ath10k-ct advantages. According to testing [3] results, the issue can be experienced even with "a 256MB device with three radios". Measured performance impact of implementing small buffers was lowering "the maximum 5 GHz throughput on an IPQ40xx device without RPS/XPS optimizations from 494/432 Mbit/s for TCP transfers (download/upload) to 438/343 Mbit/s" The patches were apparently inspired by QSDK tweaks used by ODMs for the affected devices. [0] http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020573.html [1] https://github.com/openwrt/openwrt/pull/1077 [2] https://bugs.openwrt.org/index.php?do=details&task_id=2664 [3] https://github.com/freifunk-gluon/gluon/pull/1440#issue-195607701 Signed-off-by: Paul Fertser <fercerpav@gmail.com> [Remove double CONFIG_ATH10K-CT_LEDS entry] Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2019-12-22 18:20:57 +00:00
.flags = CE_ATTR_FLAGS,
.src_nentries = 0,
.src_sz_max = 2048,
+#ifndef CONFIG_ATH10K_SMALLBUFFERS
.dest_nentries = 128,
+#else
+ .dest_nentries = 64,
+#endif
.recv_cb = ath10k_pci_htc_rx_cb,
},
ath10k-ct: switch to driver version 5.8 Since we are using mac80211 5.8, let's also switch the ath10k-ct driver to the new 5.8 version. Modify patches so they patch the new ath10k-ct driver version. Adapt 164-ath10k-commit-rates-from-mac80211.patch. Drop upstreamed 205-ath10k-Add-NL80211_EXT_FEATURE_AQL-flag.patch. Drop the other options for CT_KVER from the comment, as it is incorrect and there are too many versions to sum up and maintain there. Runtime-tested on ath79 (D-Link DAP-2695-A1, TP-Link EAP245-v3). Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
2020-09-02 19:10:38 +00:00
@@ -167,7 +175,11 @@ static const struct ce_attr pci_host_ce_
kernel: ath10k-ct: provide a build variant for small RAM devices According to many bugreports [0][1][2] the default ath10k-ct kernel module is unusable on devices with just 64 MiB RAM or with 128 MiB and dual ath10k cards. The target boards boot but eventually oom-killer starts to interfere with normal operation, so the current state is effectively broken. Since the two patches in question have a performance impact (and possibly some other unexpected side-effects) a dedicated build variant is added so that users of the low RAM devices can still benefit from all the ath10k-ct advantages. According to testing [3] results, the issue can be experienced even with "a 256MB device with three radios". Measured performance impact of implementing small buffers was lowering "the maximum 5 GHz throughput on an IPQ40xx device without RPS/XPS optimizations from 494/432 Mbit/s for TCP transfers (download/upload) to 438/343 Mbit/s" The patches were apparently inspired by QSDK tweaks used by ODMs for the affected devices. [0] http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020573.html [1] https://github.com/openwrt/openwrt/pull/1077 [2] https://bugs.openwrt.org/index.php?do=details&task_id=2664 [3] https://github.com/freifunk-gluon/gluon/pull/1440#issue-195607701 Signed-off-by: Paul Fertser <fercerpav@gmail.com> [Remove double CONFIG_ATH10K-CT_LEDS entry] Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2019-12-22 18:20:57 +00:00
.flags = CE_ATTR_FLAGS,
.src_nentries = 0,
.src_sz_max = 512,
+#ifndef CONFIG_ATH10K_SMALLBUFFERS
.dest_nentries = 512,
+#else
+ .dest_nentries = 128,
+#endif
.recv_cb = ath10k_pci_htt_rx_cb,
},
ath10k-ct: switch to driver version 5.8 Since we are using mac80211 5.8, let's also switch the ath10k-ct driver to the new 5.8 version. Modify patches so they patch the new ath10k-ct driver version. Adapt 164-ath10k-commit-rates-from-mac80211.patch. Drop upstreamed 205-ath10k-Add-NL80211_EXT_FEATURE_AQL-flag.patch. Drop the other options for CT_KVER from the comment, as it is incorrect and there are too many versions to sum up and maintain there. Runtime-tested on ath79 (D-Link DAP-2695-A1, TP-Link EAP245-v3). Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
2020-09-02 19:10:38 +00:00
@@ -192,7 +204,11 @@ static const struct ce_attr pci_host_ce_
kernel: ath10k-ct: provide a build variant for small RAM devices According to many bugreports [0][1][2] the default ath10k-ct kernel module is unusable on devices with just 64 MiB RAM or with 128 MiB and dual ath10k cards. The target boards boot but eventually oom-killer starts to interfere with normal operation, so the current state is effectively broken. Since the two patches in question have a performance impact (and possibly some other unexpected side-effects) a dedicated build variant is added so that users of the low RAM devices can still benefit from all the ath10k-ct advantages. According to testing [3] results, the issue can be experienced even with "a 256MB device with three radios". Measured performance impact of implementing small buffers was lowering "the maximum 5 GHz throughput on an IPQ40xx device without RPS/XPS optimizations from 494/432 Mbit/s for TCP transfers (download/upload) to 438/343 Mbit/s" The patches were apparently inspired by QSDK tweaks used by ODMs for the affected devices. [0] http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020573.html [1] https://github.com/openwrt/openwrt/pull/1077 [2] https://bugs.openwrt.org/index.php?do=details&task_id=2664 [3] https://github.com/freifunk-gluon/gluon/pull/1440#issue-195607701 Signed-off-by: Paul Fertser <fercerpav@gmail.com> [Remove double CONFIG_ATH10K-CT_LEDS entry] Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2019-12-22 18:20:57 +00:00
.flags = CE_ATTR_FLAGS,
.src_nentries = 0,
.src_sz_max = 2048,
+#ifndef CONFIG_ATH10K_SMALLBUFFERS
.dest_nentries = 128,
+#else
+ .dest_nentries = 96,
+#endif
.recv_cb = ath10k_pci_pktlog_rx_cb,
},
Reference in New Issue Copy Permalink