Re: [PATCH v2 3/6] ath79: D-Link DAP-2680 A1: convert ath10k caldata to nvmem

2022-06-17 Thread Christian Lamparter 

Hi,

On 18/06/2022 01:26, Sebastian Schaper wrote:

unfortunately, testing these changes on DAP-2680 resulted in board-2.bin
not being loaded, the driver is only looking for board.bin instead.

[   12.476846] ath10k 5.15 driver, optimized for CT firmware, probing pci 
device: 0x46.
[   12.486197] ath10k_pci :00:00.0: enabling device ( -> 0002)
[   12.492883] ath10k_pci :00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 
0 reset_mode 0
[   15.751865] ath10k_pci :00:00.0: qca9984/qca9994 hw1.0 target 0x0100 
chip_id 0x sub 168c:cafe
[   15.761962] ath10k_pci :00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 
1 testmode 0
[   15.781211] ath10k_pci :00:00.0: firmware ver 
10.4b-ct-9984-fW-13-5ae337bb1 api 5 features 
mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT
 crc32 7ea63dc5
[   18.114113] ath10k_pci :00:00.0: Loading BDF type 0
[   18.123845] ath10k_pci :00:00.0: failed to fetch board data for 
bus=pci,vendor=168c,device=0046,subsystem-vendor=168c,subsystem-device=cafe 
from ath10k/QCA9984/hw1.0/board-2.bin
[   18.737015] ath10k_pci :00:00.0: failed to fetch board-2.bin or 
board.bin from ath10k/QCA9984/hw1.0
[   18.746595] ath10k_pci :00:00.0: failed to fetch board file: -12
[   18.767513] ath10k_pci :00:00.0: could not probe fw (-12)


Technically, the Wave-2 chips like the 9984 need the "pre-calibration"
as the nvmem-cell-names string over "calibration". If you change it,
it will  pick up the matching entry in board-2.bin...


Creating a symlink named board.bin does make it work, it turns out the
11-ath10k-caldata script is never called for $FIRMWARE `board-2.bin`.

This is probably the reason a symlink was used with many ath10k devices,
but unfortunately I am not familiar with the details of board files loading, or
how this should be handled when caldata is extracted via the nvmem driver.


the symlink from the pre-cal to the board.bin is an established OpenWrt
workaround. Because the entry in the board-2.bin might not be the one
you want. It could be that your device's ODM changed the RF layout over
the reference boardfiles and you get anything from slightly worse to
almost no range/performance. Using the pre-cal for the boardfile too
was found to be the easy fix and provied an improvement.

Qualcomm's official way to address this is to add a variant property to the
ath10k node and upstream the boardfile from the vendor through their process:


Regards,
Christian


Am 13.06.22 um 22:15 schrieb Sander Vanheule:

Add the PCIe node for the ath10k radio to the devicetree, and refer to
the art partition for the calibration data using nvmem-cells.

MAC address assignment is moved to '10_fix_wifi_mac', so the device can
then be removed from the caldata extraction script '11-ath10k-caldata'.

Cc: Sebastian Schaper 
Signed-off-by: Sander Vanheule 
---
  .../linux/ath79/dts/qca9558_dlink_dap-2680-a1.dts  | 14 ++
  .../etc/hotplug.d/firmware/11-ath10k-caldata   |  6 --
  .../etc/hotplug.d/ieee80211/10_fix_wifi_mac    |  7 ++-
  3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/target/linux/ath79/dts/qca9558_dlink_dap-2680-a1.dts 
b/target/linux/ath79/dts/qca9558_dlink_dap-2680-a1.dts
index 0593fd29f418..09503da52b60 100644
--- a/target/linux/ath79/dts/qca9558_dlink_dap-2680-a1.dts
+++ b/target/linux/ath79/dts/qca9558_dlink_dap-2680-a1.dts
@@ -79,4 +79,18 @@
   {
  status = "okay";
+
+    wifi@0,0 {
+    compatible = "qcom,ath10k";
+    reg = <0 0 0 0 0>;
+
+    nvmem-cells = <_ath10k>;
+    nvmem-cell-names = "calibration";
+    };
+};
+
+ {
+    cal_ath10k: calibration@5000 {
+    reg = <0x5000 0x2f20>;
+    };
  };
diff --git 
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
 
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 668fd76af3a4..74a625ca840c 100644
--- 
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ 
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -199,12 +199,6 @@ case "$FIRMWARE" in
  /lib/firmware/ath10k/QCA9888/hw2.0/board.bin
  rm /lib/firmware/ath10k/QCA9888/hw2.0/board-2.bin
  ;;
-    dlink,dap-2680-a1)
-    caldata_extract "art" 0x5000 0x2f20
-    ath10k_patch_mac $(mtd_get_mac_ascii bdcfg wlanmac_a)
-    ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \
-    /lib/firmware/ath10k/QCA9888/hw2.0/board.bin
-    ;;
  dlink,dir-842-c1|\
  dlink,dir-842-c2|\
  dlink,dir-842-c3)
diff --git 
a/target/linux/ath79/generic/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac

Re: [PATCH v2 3/6] ath79: D-Link DAP-2680 A1: convert ath10k caldata to nvmem

2022-06-17 Thread Sebastian Schaper 

Hi Sander,

unfortunately, testing these changes on DAP-2680 resulted in board-2.bin
not being loaded, the driver is only looking for board.bin instead.

[   12.476846] ath10k 5.15 driver, optimized for CT firmware, probing 
pci device: 0x46.

[   12.486197] ath10k_pci :00:00.0: enabling device ( -> 0002)
[   12.492883] ath10k_pci :00:00.0: pci irq legacy oper_irq_mode 1 
irq_mode 0 reset_mode 0
[   15.751865] ath10k_pci :00:00.0: qca9984/qca9994 hw1.0 target 
0x0100 chip_id 0x sub 168c:cafe
[   15.761962] ath10k_pci :00:00.0: kconfig debug 0 debugfs 1 
tracing 0 dfs 1 testmode 0
[   15.781211] ath10k_pci :00:00.0: firmware ver 
10.4b-ct-9984-fW-13-5ae337bb1 api 5 features 
mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT 
crc32 7ea63dc5

[   18.114113] ath10k_pci :00:00.0: Loading BDF type 0
[   18.123845] ath10k_pci :00:00.0: failed to fetch board data for 
bus=pci,vendor=168c,device=0046,subsystem-vendor=168c,subsystem-device=cafe 
from ath10k/QCA9984/hw1.0/board-2.bin
[   18.737015] ath10k_pci :00:00.0: failed to fetch board-2.bin or 
board.bin from ath10k/QCA9984/hw1.0

[   18.746595] ath10k_pci :00:00.0: failed to fetch board file: -12
[   18.767513] ath10k_pci :00:00.0: could not probe fw (-12)

Creating a symlink named board.bin does make it work, it turns out the
11-ath10k-caldata script is never called for $FIRMWARE `board-2.bin`.

This is probably the reason a symlink was used with many ath10k devices,
but unfortunately I am not familiar with the details of board files 
loading, or

how this should be handled when caldata is extracted via the nvmem driver.

Best,
Sebastian


Am 13.06.22 um 22:15 schrieb Sander Vanheule:

Add the PCIe node for the ath10k radio to the devicetree, and refer to
the art partition for the calibration data using nvmem-cells.

MAC address assignment is moved to '10_fix_wifi_mac', so the device can
then be removed from the caldata extraction script '11-ath10k-caldata'.

Cc: Sebastian Schaper 
Signed-off-by: Sander Vanheule 
---
  .../linux/ath79/dts/qca9558_dlink_dap-2680-a1.dts  | 14 ++
  .../etc/hotplug.d/firmware/11-ath10k-caldata   |  6 --
  .../etc/hotplug.d/ieee80211/10_fix_wifi_mac|  7 ++-
  3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/target/linux/ath79/dts/qca9558_dlink_dap-2680-a1.dts 
b/target/linux/ath79/dts/qca9558_dlink_dap-2680-a1.dts
index 0593fd29f418..09503da52b60 100644
--- a/target/linux/ath79/dts/qca9558_dlink_dap-2680-a1.dts
+++ b/target/linux/ath79/dts/qca9558_dlink_dap-2680-a1.dts
@@ -79,4 +79,18 @@
  
   {

status = "okay";
+
+   wifi@0,0 {
+   compatible = "qcom,ath10k";
+   reg = <0 0 0 0 0>;
+
+   nvmem-cells = <_ath10k>;
+   nvmem-cell-names = "calibration";
+   };
+};
+
+ {
+   cal_ath10k: calibration@5000 {
+   reg = <0x5000 0x2f20>;
+   };
  };
diff --git 
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
 
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 668fd76af3a4..74a625ca840c 100644
--- 
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ 
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -199,12 +199,6 @@ case "$FIRMWARE" in
/lib/firmware/ath10k/QCA9888/hw2.0/board.bin
rm /lib/firmware/ath10k/QCA9888/hw2.0/board-2.bin
;;
-   dlink,dap-2680-a1)
-   caldata_extract "art" 0x5000 0x2f20
-   ath10k_patch_mac $(mtd_get_mac_ascii bdcfg wlanmac_a)
-   ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \
-   /lib/firmware/ath10k/QCA9888/hw2.0/board.bin
-   ;;
dlink,dir-842-c1|\
dlink,dir-842-c2|\
dlink,dir-842-c3)
diff --git 
a/target/linux/ath79/generic/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac 
b/target/linux/ath79/generic/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
index a4f82c54e271..d5a2471a99a9 100644
--- 
a/target/linux/ath79/generic/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
+++ 
b/target/linux/ath79/generic/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
@@ -27,12 +27,17 @@ case "$board" in
mtd_get_mac_ascii bdcfg "wlanmac" > /sys${DEVPATH}/macaddress
;;
dlink,dap-2660-a1|\
-   dlink,dap-2680-a1|\
dlink,dap-2695-a1|\
dlink,dap-3662-a1)
[ "$PHYNBR" -eq 1 ] && \
mtd_get_mac_ascii bdcfg "wlanmac" > 
/sys${DEVPATH}/macaddress
;;
+   dlink,dap-2680-a1)
+   [ "$PHYNBR" -eq 0 ] && \
+   mtd_get_mac_ascii bdcfg "wlanmac_a"

[PATCH 0/2] ramips: add support for ZyXEL LTE3301-Plus

2022-06-17 Thread André Valentin 
The ZyXEL LTE3301-PLUS is an 4G indoor CPE with 2 external LTE antennas.

Specifications:

 - SoC: MediaTek MT7621AT
 - RAM: 256 MB
 - Flash: 128 MB MB NAND (MX30LF1G18AC)
 - WiFi: MediaTek MT7615E
 - Switch: 4 LAN ports (Gigabit)
 - LTE: Quectel EG506 connected by USB3 to SoC
 - SIM: 1 micro-SIM slot
 - USB: USB3 port
 - Buttons: Reset, WPS
 - LEDs: Multicolour power, internet, LTE, signal, Wifi, USB
 - Power: 12V, 1.5A

The device is built as an indoor ethernet to LTE bridge or router with
Wifi.

André Valentin (2):
  ramips: add support for ZyXEL LTE3301-Plus
  package/uboot-envtools: add support for ZyXEL LTE3301-plus

 package/boot/uboot-envtools/files/ramips  |   3 +
 .../ramips/dts/mt7621_zyxel_lte3301-plus.dts  | 217 ++
 target/linux/ramips/image/mt7621.mk   |  19 ++
 .../mt7621/base-files/etc/board.d/01_leds |   3 +
 .../mt7621/base-files/etc/board.d/02_network  |   3 +-
 .../base-files/etc/board.d/03_gpio_switches   |   4 +
 .../mt7621/base-files/etc/init.d/bootcount|   5 +
 .../mt7621/base-files/lib/upgrade/platform.sh |   1 +
 8 files changed, 254 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts

-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] package/uboot-envtools: add support for ZyXEL LTE3301-plus

2022-06-17 Thread André Valentin 
This add support for the uboot env allow to enable serial console.
---
 package/boot/uboot-envtools/files/ramips | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/package/boot/uboot-envtools/files/ramips 
b/package/boot/uboot-envtools/files/ramips
index eebc08d65d..fbbb5a014b 100644
--- a/package/boot/uboot-envtools/files/ramips
+++ b/package/boot/uboot-envtools/files/ramips
@@ -68,6 +68,9 @@ xiaomi,mi-router-ac2100|\
 xiaomi,redmi-router-ac2100)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x2"
;;
+zyxel,lte3301-plus)
+   ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x8"
+   ;;
 zyxel,nr7101)
idx="$(find_mtd_index Config)"
[ -n "$idx" ] && \
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] ramips: add support for ZyXEL LTE3301-Plus

2022-06-17 Thread André Valentin 
The ZyXEL LTE3301-PLUS is an 4G indoor CPE with 2 external LTE antennas.

Specifications:

 - SoC: MediaTek MT7621AT
 - RAM: 256 MB
 - Flash: 128 MB MB NAND (MX30LF1G18AC)
 - WiFi: MediaTek MT7615E
 - Switch: 4 LAN ports (Gigabit)
 - LTE: Quectel EG506 connected by USB3 to SoC
 - SIM: 1 micro-SIM slot
 - USB: USB3 port
 - Buttons: Reset, WPS
 - LEDs: Multicolour power, internet, LTE, signal, Wifi, USB
 - Power: 12V, 1.5A

The device is built as an indoor ethernet to LTE bridge or router with
Wifi.

UART Serial:

57600N1
Located on populated 5 pin header J5:

 [o] GND
 [ ] key - no pin
 [o] RX
 [o] TX
 [o] 3.3V Vcc

MAC assignment:
lan:  98:0d:67:ee:85:54 (base, on the device back)
wlan: 98:0d:67:ee:85:55

Installation from web GUI:

- Log in as "admin" on http://192.168.1.1/
- Upload OpenWrt initramfs-recovery.bin image on the
  Maintenance -> Firmware page
- Wait for OpenWrt to boot and ssh to root@192.168.1.1
- format ubi device: ubiformat /dev/mtd6
- attach ubi device: ubiattach -m6
- create rootfs volume: ubimkvol /dev/ubi0 -n0 -N rootfs -s 1MiB
- rootfs_data volume: ubimkvol /dev/ubi0 -n1 -N rootfs_data -s 1MiB
- run sysupgrade with sysupgrade image

For more details about flashing see
commit 2449a632084b ("ramips: mt7621: Add support for ZyXEL NR7101").

Please note that this commit is needed:
firmware-utils: add marcant changes for ZyXEL NBG6716 and LTE3301-PLUS

Signed-off-by: André Valentin 
---
 .../ramips/dts/mt7621_zyxel_lte3301-plus.dts  | 217 ++
 target/linux/ramips/image/mt7621.mk   |  19 ++
 .../mt7621/base-files/etc/board.d/01_leds |   3 +
 .../mt7621/base-files/etc/board.d/02_network  |   3 +-
 .../base-files/etc/board.d/03_gpio_switches   |   4 +
 .../mt7621/base-files/etc/init.d/bootcount|   5 +
 .../mt7621/base-files/lib/upgrade/platform.sh |   1 +
 7 files changed, 251 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts

diff --git a/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts 
b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
new file mode 100644
index 00..ed8260534e
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
@@ -0,0 +1,217 @@
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "zyxel,lte3301-plus", "mediatek,mt7621-soc";
+   model = "ZyXEL LTE3301-Plus";
+
+   aliases {
+   label-mac-device = 
+   led-boot = _power;
+   led-failsafe = _power;
+   led-running = _power;
+   led-upgrade = _power;
+   };
+
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   gpio_export {
+   compatible = "gpio-export";
+   #size-cells = <0>;
+
+   power_modem {
+   gpio-export,name = "power_modem";
+   gpio-export,output = <1>;
+   gpios = < 27 GPIO_ACTIVE_LOW>;
+   };
+
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 6 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: power {
+   label = "lte3301-plus:white:power";
+   gpios = < 5 GPIO_ACTIVE_HIGH>;
+   };
+
+   wifi {
+   label = "lte3301-plus:white:wifi";
+   gpios = < 13 GPIO_ACTIVE_LOW>;
+   };
+
+   internet {
+   label = "lte3301-plus:white:internet";
+   gpios = < 23 GPIO_ACTIVE_LOW>;
+   };
+
+   usb {
+   label = "lte3301-plus:white:usb";
+   gpios = < 24 GPIO_ACTIVE_LOW>;
+   };
+
+   lte {
+   label = "lte3301-plus:white:lte";
+   gpios = < 26 GPIO_ACTIVE_LOW>;
+   };
+
+   mobile_green {
+   label = "lte3301-plus:green:mobile";
+   gpios = < 31 GPIO_ACTIVE_LOW>;
+   };
+
+   mobile_orange {
+   label = "lte3301-plus:orange:mobile";
+   gpios = < 22 GPIO_ACTIVE_LOW>;
+   };
+
+   mobile_red {
+   label = "lte3301-plus:red:mobile";
+   gpios = < 14 GPIO_ACTIVE_LOW>;
+   };
+
+   };
+
+};
+
+ {
+   status = "okay";
+
+   enable_usb_power {
+   gpio-hog;
+   line-name = "enable USB power";
+   gpios =

[PATCH] firmware-utils: Add support for ZyXEL LTE3301-Plus

2022-06-17 Thread André Valentin 
Add header mapping for ZyXEL LTE3301-Plus to zytrx.

Signed-off-by: André Valentin  
---
 src/zytrx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/zytrx.c b/src/zytrx.c
index 8c113d6..0c69b6a 100644
--- a/src/zytrx.c
+++ b/src/zytrx.c
@@ -92,6 +92,7 @@ static struct board_t {
uint32_t modelid;
 } boards[] = {
{ "MT7621A", "NR7101", 0x07010001 },
+   { "MT7621A", "LTE3301-PLUS", 0x03030001  },
{}
 };
 
-- 
2.30.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Testing network / NAT performance

2022-06-17 Thread Ansuel Smith 
Il giorno ven 17 giu 2022 alle ore 13:51 Hauke Mehrtens
 ha scritto:
>
> Hi Rafal,
>
> Thank you for your detailed analyses and also for the detailed report.
> This is very helpful when I ran into this problem.
>
> Can we somehow automate it so that we get notified a day after a bad
> change was committed about performance regression and not one year after?
>
> On 6/14/22 15:16, Rafał Miłecki wrote:
> > On 12.06.2022 21:58, Rafał Miłecki wrote:
> >> 5. 7125323b81d7 ("bcm53xx: switch to kernel 5.4")
> >>
> >> Improved network speed by 25% (256 Mb/s → 320 Mb/s).
> >>
> >> I didn't have time to bisect this *improvement* to a single kernel
> >> commit. I tried profiling but it isn't obvious to me what caused that
> >> improvement.
> >>
> >> Kernel 4.19:
> >>  11.94%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> v7_dma_inv_range
> >>   7.06%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> l2c210_inv_range
> >>   3.37%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> v7_dma_clean_range
> >>   2.80%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> l2c210_clean_range
> >>   2.67%  ksoftirqd/0  [kernel.kallsyms]   [k] bgmac_poll
> >>   2.63%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> __dev_queue_xmit
> >>   2.43%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> __netif_receive_skb_core
> >>   2.13%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> bgmac_start_xmit
> >>   1.82%  ksoftirqd/0  [kernel.kallsyms]   [k] nf_hook_slow
> >>   1.54%  ksoftirqd/0  [kernel.kallsyms]   [k] ip_forward
> >>   1.50%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> dma_cache_maint_page
> >>
> >> Kernel 5.4:
> >>  14.53%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> v7_dma_inv_range
> >>   8.02%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> l2c210_inv_range
> >>   3.32%  ksoftirqd/0  [kernel.kallsyms]   [k] bgmac_poll
> >>   3.28%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> v7_dma_clean_range
> >>   3.12%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> __netif_receive_skb_core
> >>   2.70%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> l2c210_clean_range
> >>   2.46%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> __dev_queue_xmit
> >>   2.26%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> bgmac_start_xmit
> >>   1.73%  ksoftirqd/0  [kernel.kallsyms]   [k]
> >> __dma_page_dev_to_cpu
> >>   1.72%  ksoftirqd/0  [kernel.kallsyms]   [k] nf_hook_slow
> >
> > Riddle solved. Change to bless/blame: 4e0c54bc5bc8 ("kernel: add support
> > for kernel 5.4").
> >
> > First of all bcm53xx uses
> > CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
> >
> >
> > OpenWrt's kernel Makefile in kernel 4.19:
> >
> > ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> > KBUILD_CFLAGS+= -Os $(EXTRA_OPTIMIZATION)
> > else
> > KBUILD_CFLAGS   += -O2 -fno-reorder-blocks -fno-tree-ch
> > $(EXTRA_OPTIMIZATION)
> > endif
> >
> >
> > OpenWrt's kernel Makefile in 5.4:
> >
> > ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
> > KBUILD_CFLAGS += -O2 $(EXTRA_OPTIMIZATION)
> > else ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3
> > KBUILD_CFLAGS += -O3 $(EXTRA_OPTIMIZATION)
> > else ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
> > KBUILD_CFLAGS += -Os -fno-reorder-blocks -fno-tree-ch $(EXTRA_OPTIMIZATION)
> > endif
> >
> >
> > As you can see 4e0c54bc5bc8 has accidentally moved -fno-reorder-blocks
> > from !CONFIG_CC_OPTIMIZE_FOR_SIZE to CONFIG_CC_OPTIMIZE_FOR_SIZE.
>
> This looks like an accident to me.
> All targets except mediatek/mt7629 are setting
> CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE in master. In Openwrt 21.02 the
> ARCHS38 target set CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3, but now it is
> also to normal performance.
>
> We should probably switch mediatek/mt7629 to
> CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE, does anyone have such a device and
> could test a patch?
>
> > I've noticed problem with -fno-reorder-blocks long time ago, see:
> > [PATCH RFC] kernel: drop -fno-reorder-blocks
> > https://patchwork.ozlabs.org/project/openwrt/patch/20190409093046.13401-1-zaj...@gmail.com/
> >
> >
> > It should really get sorted out...
>
> I would suggest to remove the -fno-reorder-blocks -fno-tree-ch options
> as they are not used.
>
>
> The next step could be Profile-guided optimization:
> https://lwn.net/Articles/830300/
> If the toolchain works properly I expect there big improvements as
> routing, forwarding and NAT is completely in the kernel and we use
> devices with small caches. Profile-guided optimization should be able to
> avoid many cache misses by better packaging the binary.
>

PGO would be a dream to accomplish but it's a nightmare to actually use it.
The kernel size grow a lot and it needs to be done correctly...
Also AFAIK it's not that easy to add support for it and it's
problematic for some
device to generate the profile data.

> Hauke
>
> ___
> openwrt-devel mailing list
>

Re: Testing network / NAT performance

2022-06-17 Thread Hauke Mehrtens 

Hi Rafal,

Thank you for your detailed analyses and also for the detailed report. 
This is very helpful when I ran into this problem.


Can we somehow automate it so that we get notified a day after a bad 
change was committed about performance regression and not one year after?


On 6/14/22 15:16, Rafał Miłecki wrote:

On 12.06.2022 21:58, Rafał Miłecki wrote:

5. 7125323b81d7 ("bcm53xx: switch to kernel 5.4")

Improved network speed by 25% (256 Mb/s → 320 Mb/s).

I didn't have time to bisect this *improvement* to a single kernel
commit. I tried profiling but it isn't obvious to me what caused that
improvement.

Kernel 4.19:
 11.94%  ksoftirqd/0  [kernel.kallsyms]   [k] 
v7_dma_inv_range
  7.06%  ksoftirqd/0  [kernel.kallsyms]   [k] 
l2c210_inv_range
  3.37%  ksoftirqd/0  [kernel.kallsyms]   [k] 
v7_dma_clean_range
  2.80%  ksoftirqd/0  [kernel.kallsyms]   [k] 
l2c210_clean_range

  2.67%  ksoftirqd/0  [kernel.kallsyms]   [k] bgmac_poll
  2.63%  ksoftirqd/0  [kernel.kallsyms]   [k] 
__dev_queue_xmit
  2.43%  ksoftirqd/0  [kernel.kallsyms]   [k] 
__netif_receive_skb_core
  2.13%  ksoftirqd/0  [kernel.kallsyms]   [k] 
bgmac_start_xmit

  1.82%  ksoftirqd/0  [kernel.kallsyms]   [k] nf_hook_slow
  1.54%  ksoftirqd/0  [kernel.kallsyms]   [k] ip_forward
  1.50%  ksoftirqd/0  [kernel.kallsyms]   [k] 
dma_cache_maint_page


Kernel 5.4:
 14.53%  ksoftirqd/0  [kernel.kallsyms]   [k] 
v7_dma_inv_range
  8.02%  ksoftirqd/0  [kernel.kallsyms]   [k] 
l2c210_inv_range

  3.32%  ksoftirqd/0  [kernel.kallsyms]   [k] bgmac_poll
  3.28%  ksoftirqd/0  [kernel.kallsyms]   [k] 
v7_dma_clean_range
  3.12%  ksoftirqd/0  [kernel.kallsyms]   [k] 
__netif_receive_skb_core
  2.70%  ksoftirqd/0  [kernel.kallsyms]   [k] 
l2c210_clean_range
  2.46%  ksoftirqd/0  [kernel.kallsyms]   [k] 
__dev_queue_xmit
  2.26%  ksoftirqd/0  [kernel.kallsyms]   [k] 
bgmac_start_xmit
  1.73%  ksoftirqd/0  [kernel.kallsyms]   [k] 
__dma_page_dev_to_cpu

  1.72%  ksoftirqd/0  [kernel.kallsyms]   [k] nf_hook_slow


Riddle solved. Change to bless/blame: 4e0c54bc5bc8 ("kernel: add support
for kernel 5.4").

First of all bcm53xx uses
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y


OpenWrt's kernel Makefile in kernel 4.19:

ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS    += -Os $(EXTRA_OPTIMIZATION)
else
KBUILD_CFLAGS   += -O2 -fno-reorder-blocks -fno-tree-ch 
$(EXTRA_OPTIMIZATION)

endif


OpenWrt's kernel Makefile in 5.4:

ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
KBUILD_CFLAGS += -O2 $(EXTRA_OPTIMIZATION)
else ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3
KBUILD_CFLAGS += -O3 $(EXTRA_OPTIMIZATION)
else ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os -fno-reorder-blocks -fno-tree-ch $(EXTRA_OPTIMIZATION)
endif


As you can see 4e0c54bc5bc8 has accidentally moved -fno-reorder-blocks
from !CONFIG_CC_OPTIMIZE_FOR_SIZE to CONFIG_CC_OPTIMIZE_FOR_SIZE.


This looks like an accident to me.
All targets except mediatek/mt7629 are setting 
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE in master. In Openwrt 21.02 the 
ARCHS38 target set CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3, but now it is 
also to normal performance.


We should probably switch mediatek/mt7629 to 
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE, does anyone have such a device and 
could test a patch?



I've noticed problem with -fno-reorder-blocks long time ago, see:
[PATCH RFC] kernel: drop -fno-reorder-blocks
https://patchwork.ozlabs.org/project/openwrt/patch/20190409093046.13401-1-zaj...@gmail.com/ 



It should really get sorted out...


I would suggest to remove the -fno-reorder-blocks -fno-tree-ch options 
as they are not used.



The next step could be Profile-guided optimization:
https://lwn.net/Articles/830300/
If the toolchain works properly I expect there big improvements as 
routing, forwarding and NAT is completely in the kernel and we use 
devices with small caches. Profile-guided optimization should be able to 
avoid many cache misses by better packaging the binary.


Hauke

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: make Netgear GS108T v3 u-boot env partition writable

2022-06-17 Thread Bjørn Mork 
Sander Vanheule  writes:
> On Thu, 2022-06-16 at 22:28 +0200, Stijn Segers wrote:
>> Signed-off-by: Stijn Segers 
>
> You need to add at least one line describing why this change is needed; now 
> you
> only have a commit title. Just mentioning that you want to be able to modify 
> the
> u-boot-env from userspace should be enough.

Could even use the real usecase example from the forum as body. Then we
have that documented here as well.


Bjørn

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] utrace: fix memory leak

2022-06-17 Thread junnanx . xu 
From: Junnan Xu 

Fixes following memory leak:

  14 bytes in 1 blocks are definitely lost in loss record 1 of 5
 at 0x4079514: malloc (vg_replace_malloc.c:309)
 by 0x4049A04: vasprintf (vasprintf.c:13)
 by 0x4046354: asprintf (asprintf.c:10)
 by 0x80491A9: main (in /root/utrace)

  134 bytes in 1 blocks are definitely lost in loss record 3 of 5
 at 0x4079514: malloc (vg_replace_malloc.c:309)
 by 0x4049A04: vasprintf (vasprintf.c:13)
 by 0x4046354: asprintf (asprintf.c:10)
 by 0x8049208: main (in /root/utrace)

Signed-off-by: Junnan Xu 
---
 trace/trace.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/trace/trace.c b/trace/trace.c
index d895798..6fd321f 100644
--- a/trace/trace.c
+++ b/trace/trace.c
@@ -381,6 +381,10 @@ int main(int argc, char **argv, char **envp)
ULOG_ERR("failed to exec %s: %m\n", _argv[0]);
 
free(_argv);
+   if (_envp[0])
+   free(_envp[0]);
+   if (newenv == 2 && _envp[1])
+   free(_envp[1]);
free(_envp);
return ret;
}
-- 
2.21.0.windows.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek: make Netgear GS108T v3 u-boot env partition writable

2022-06-17 Thread Sander Vanheule 
Hi Stijn,

On Thu, 2022-06-16 at 22:28 +0200, Stijn Segers wrote:
> Signed-off-by: Stijn Segers 

You need to add at least one line describing why this change is needed; now you
only have a commit title. Just mentioning that you want to be able to modify the
u-boot-env from userspace should be enough.

Best,
Sander

> ---
>  target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi
> b/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi
> index 7eccfcb5a2..fd44543bb4 100644
> --- a/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi
> +++ b/target/linux/realtek/dts-5.10/rtl8380_netgear_gigabit_1xx.dtsi
> @@ -24,7 +24,6 @@
> partition@e {
> label = "u-boot-env";
> reg = <0x00e 0x001>;
> -   read-only;
> };
>  
> partition@f {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel