Re: [PATCH RFT] ramips: use -fno-reorder-blocks for kernel compilation
On 20.06.2022 22:24, Rafał Miłecki wrote: It seems to affect (improve) NAT masquarade performance on ramips. This is SoC family specific (that flag worsens Broadcom Northstar NAT speeds) so it can't be applied to all devices. It may fix https://github.com/openwrt/openwrt/issues/8778 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] bcm53xx: disable GRO support at kernel level
On Mon, Jun 20, 2022 at 2:33 AM Rafał Miłecki wrote: > > On 10.06.2022 15:16, Rafał Miłecki wrote: > > This improves NAT masquarade network performance. > > > > An alternative to kernel change would be runtime setup but that requires > > ethtool and identifying relevant network interface and all related > > switch ports interfaces. > > I sent another patch that should supersede this one: > [PATCH] bcm53xx: disable GRO by default at kernel level > https://patchwork.ozlabs.org/project/openwrt/patch/20220620082120.11714-1-zaj...@gmail.com/ > > It's probably a better idea to disable GRO *by default* (and allow > re-enabling it). Reminds me of this patch: https://github.com/openwrt/openwrt/commit/13e5e473699b92f171205e0f5c57c9ebe7922492 which was subsequently reverted because of slower routing performance Is this patch the same as using napi_gro_receive and passing NETIF_F_GRO ? > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Donation for Developers: Easybox 904xdsl - Lantiq XRX200, 512MB ROM, 128MB RAM, Color LCD Screen
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Because for sure some developers are not following the openwrt forum all the time, here is a copy of my forum post from here: https://forum.openwrt.org/t/donation-for-developers-easybox-904xdsl-lantiq-xrx200-512mb-rom-128mb-ram-color-lcd-screen/130223 A special offer for OpenWrt developers in europe: Free Lantiq XRX200 Router with huge 512MB ROM, 128MB RAM, VDSL Vectoring, and much more:https://openwrt.org/toh/astoria/arcadyan_astoria_easybox_904xdsl_r01 This is a special device where some developers have spend much time in the last years to get it working with OpenWrt. It have a working LCD-Screen in OpenWrt. Also a special OpenWrt boot animation for the bootloader exist. What you would get: A free device send to your address to finally get this great OpenWrt router mainlined. The device would be already preinstalled with a prebuild OpenWrt image. Current state: Wifi is kind of working, everything else is working fine. You can configute if you want two lantiq CPU cores active and no phone line working or one core for phone and one core for normal system. With the 512MB ROM you can install asterisk and many other things and with the LCD color screen you can display what you like. The 128MB RAM make all of this possible. USB for external hard disk (NAS, rtorrent, ... )is also there. What i hope to reach with spending time to buy, install all the devices and then send them for free to developers: This device get finally merged upstream. In OpenWrt 22.03-rc4 the latest Lantiq VDSL vectoring patches got backported for OpenWrt stable releases. The easybox 904xdsl have way too good hardware to not be supported by OpenWrt. The wifi is not the main issue, its the missing upstream support. Even without wifi mainline OpenWrt would be a huge benefit. I am contacting the known OpenWrt lantiq developers with following email address: openwrt-donations-904x...@proton.me Also other already active (some device ported, ...) OpenWrt developers could send me a mail if i have not already send them a mail. Famous threads that affect the device: https://forum.openwrt.org/t/support-for-easybox-904-lte/14478 https://forum.openwrt.org/t/lantiq-xrx200-easybox-904xdsl-and-speedport-w-921v-build/77105 https://forum.openwrt.org/t/vectoring-on-lantiq-vrx200-vr9-missing-callback-for-sending-error-samples/104046 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH RFT] ramips: use -fno-reorder-blocks for kernel compilation
From: Rafał Miłecki It seems to affect (improve) NAT masquarade performance on ramips. This is SoC family specific (that flag worsens Broadcom Northstar NAT speeds) so it can't be applied to all devices. Signed-off-by: Rafał Miłecki --- config/Config-devel.in | 1 + 1 file changed, 1 insertion(+) diff --git a/config/Config-devel.in b/config/Config-devel.in index a068f694e5..2e4613f171 100644 --- a/config/Config-devel.in +++ b/config/Config-devel.in @@ -76,6 +76,7 @@ menuconfig DEVEL config KERNEL_CFLAGS string "Kernel extra CFLAGS" if DEVEL + default "-fno-reorder-blocks" if TARGET_ramips default "" config EXTERNAL_KERNEL_TREE -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] kernel: drop patch adding hardcoded kernel compilation flags
On 6/15/22 12:36, Rafał Miłecki wrote:
From: Rafał Miłecki
1. KCFLAGS should be used for custom flags
2. Optimization flags are arch / SoC specific
3. -fno-reorder-blocks may *worsen* network performace on some SoCs
4. Usage of flags was *reversed* since 5.4 and noone reported that
If we really need custom flags then CONFIG_KERNEL_CFLAGS should get
default value adjusted properly (per target).
Ref: 4e0c54bc5bc8 ("kernel: add support for kernel 5.4")
Link: http://lists.openwrt.org/pipermail/openwrt-devel/2022-June/038853.html
Link:
https://patchwork.ozlabs.org/project/openwrt/patch/20190409093046.13401-1-zaj...@gmail.com/
Cc: Felix Fietkau
Cc: Hauke Mehrtens
Cc: Rui Salvaterra
Signed-off-by: Rafał Miłecki
Acked-by: Hauke Mehrtens
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mac80211: brcmfmac: allow setting MAC from NVMEM cells
From: Tomasz Maciej Nowak
The MAC can be stored in OTP memory or in flash memory, currently the
driver could read it only from OTP. Backport the patch allowing setting
the MAC address from flash. Some modules have the OTP programmed but
the ODM/OEM decided to overwrite it with value stored in flash.
Signed-off-by: Tomasz Maciej Nowak
---
...etting-wlan-MAC-address-using-device.patch | 103 ++
...-in-driver-tables-with-country-codes.patch | 4 +-
.../mac80211/patches/brcm/998-survey.patch| 4 +-
3 files changed, 107 insertions(+), 4 deletions(-)
create mode 100644
package/kernel/mac80211/patches/brcm/001-brcmfmac-allow-setting-wlan-MAC-address-using-device.patch
diff --git
a/package/kernel/mac80211/patches/brcm/001-brcmfmac-allow-setting-wlan-MAC-address-using-device.patch
b/package/kernel/mac80211/patches/brcm/001-brcmfmac-allow-setting-wlan-MAC-address-using-device.patch
new file mode 100644
index ..03d9f8ecd8c1
--- /dev/null
+++
b/package/kernel/mac80211/patches/brcm/001-brcmfmac-allow-setting-wlan-MAC-address-using-device.patch
@@ -0,0 +1,103 @@
+From 716c220b4d990a4fe7800d0685ca69dee99e4e8f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pavel=20L=C3=B6bl?=
+Date: Fri, 6 May 2022 06:42:46 +0200
+Subject: [PATCH] brcmfmac: allow setting wlan MAC address using device tree
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+This allows firmware to provide MAC address using device tree. Like in
+case there is no MAC burned in wlan NVRAM.
+
+Signed-off-by: Pavel L??bl
+Signed-off-by: Kalle Valo
+Link: https://lore.kernel.org/r/20220506044246.67146-1-pa...@loebl.cz
+---
+ .../broadcom/brcm80211/brcmfmac/common.c | 23 ++-
+ .../broadcom/brcm80211/brcmfmac/common.h | 1 +
+ .../broadcom/brcm80211/brcmfmac/core.c| 4 +++-
+ .../wireless/broadcom/brcm80211/brcmfmac/of.c | 3 +++
+ 4 files changed, 24 insertions(+), 7 deletions(-)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+@@ -202,13 +202,24 @@ int brcmf_c_preinit_dcmds(struct brcmf_i
+ char *ptr;
+ s32 err;
+
+- /* retreive mac address */
+- err = brcmf_fil_iovar_data_get(ifp, "cur_etheraddr", ifp->mac_addr,
+- sizeof(ifp->mac_addr));
+- if (err < 0) {
+- bphy_err(drvr, "Retrieving cur_etheraddr failed, %d\n", err);
+- goto done;
++ if (is_valid_ether_addr(ifp->mac_addr)) {
++ /* set mac address */
++ err = brcmf_fil_iovar_data_set(ifp, "cur_etheraddr",
ifp->mac_addr,
++ ETH_ALEN);
++ if (err < 0) {
++ bphy_err(ifp->drvr, "Setting cur_etheraddr failed,
%d\n", err);
++ goto done;
++ }
++ } else {
++ /* retrieve mac address */
++ err = brcmf_fil_iovar_data_get(ifp, "cur_etheraddr",
ifp->mac_addr,
++ sizeof(ifp->mac_addr));
++ if (err < 0) {
++ bphy_err(drvr, "Retrieving cur_etheraddr failed, %d\n",
err);
++ goto done;
++ }
+ }
++
+ memcpy(ifp->drvr->mac, ifp->mac_addr, sizeof(ifp->drvr->mac));
+ memcpy(ifp->drvr->wiphy->perm_addr, ifp->drvr->mac, ETH_ALEN);
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
+@@ -50,6 +50,7 @@ struct brcmf_mp_device {
+ boolignore_probe_fail;
+ struct brcmfmac_pd_cc *country_codes;
+ const char *board_type;
++ unsigned char mac[ETH_ALEN];
+ union {
+ struct brcmfmac_sdio_pd sdio;
+ } bus;
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+@@ -7,6 +7,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -1226,7 +1227,8 @@ static int brcmf_bus_started(struct brcm
+ brcmf_dbg(TRACE, "\n");
+
+ /* add primary networking interface */
+- ifp = brcmf_add_if(drvr, 0, 0, false, "wlan%d", NULL);
++ ifp = brcmf_add_if(drvr, 0, 0, false, "wlan%d",
++ is_valid_ether_addr(drvr->settings->mac) ?
drvr->settings->mac : NULL);
+ if (IS_ERR(ifp))
+ return PTR_ERR(ifp);
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+@@ -5,6 +5,7 @@
+ #include
+ #include
+ #include
++#include
+
+ #include
+ #include "debug.h"
+@@ -97,6 +98,8 @@ void brcmf_of_probe(struct device *dev,
+ if (err)
+ brcmf_err("failed to get OF country code map (err=%d)\n", err);
+
++ of_get_mac_address(np, settings->mac);
++
+ if (bus_type !=
[PATCH] generic: 5.15: enable LIB_BLAKE2S_GENERIC
From: Tomasz Maciej Nowak
This is now built-in, enable so it won't propagate on target configs.
Fixes: 79e7a2552e89 ("kernel: bump 5.15 to 5.15.44")
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/generic/config-5.15| 1 +
target/linux/rockchip/armv8/config-5.15 | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/generic/config-5.15 b/target/linux/generic/config-5.15
index a2644c987663..ce9e39b9dc89 100644
--- a/target/linux/generic/config-5.15
+++ b/target/linux/generic/config-5.15
@@ -1177,6 +1177,7 @@ CONFIG_CRYPTO_KPP=y
CONFIG_CRYPTO_KPP2=y
CONFIG_CRYPTO_LIB_AES=y
CONFIG_CRYPTO_LIB_ARC4=y
+CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
# CONFIG_CRYPTO_LIB_CHACHA is not set
# CONFIG_CRYPTO_LIB_CHACHA20POLY1305 is not set
# CONFIG_CRYPTO_LIB_CURVE25519 is not set
diff --git a/target/linux/rockchip/armv8/config-5.15
b/target/linux/rockchip/armv8/config-5.15
index 3afeba2dd41d..45313649a44c 100644
--- a/target/linux/rockchip/armv8/config-5.15
+++ b/target/linux/rockchip/armv8/config-5.15
@@ -160,7 +160,6 @@ CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_ARM64_CE=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_GHASH_ARM64_CE=y
-CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_SIMD=y
CONFIG_DCACHE_WORD_ACCESS=y
--
2.36.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: clean-up after kernel 5.4 removal
From: Tomasz Maciej Nowak These narrowments are no longer useful, since there's no lower version than 5.10 supported in tree. Signed-off-by: Tomasz Maciej Nowak --- package/kernel/linux/modules/crypto.mk | 2 +- package/kernel/linux/modules/fs.mk | 10 -- package/kernel/linux/modules/i2c.mk| 2 +- package/kernel/linux/modules/netdevices.mk | 18 +++--- package/kernel/linux/modules/netfilter.mk | 4 +--- package/kernel/linux/modules/other.mk | 4 +--- package/kernel/linux/modules/sound.mk | 3 +-- package/kernel/linux/modules/usb.mk| 6 +++--- 8 files changed, 19 insertions(+), 30 deletions(-) diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index d43100703eb3..ed4e51079ef0 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -42,7 +42,7 @@ define KernelPackage/crypto-aead CONFIG_CRYPTO_AEAD2 FILES:= \ $(LINUX_DIR)/crypto/aead.ko \ - $(LINUX_DIR)/crypto/geniv.ko@ge5.10 + $(LINUX_DIR)/crypto/geniv.ko AUTOLOAD:=$(call AutoLoad,09,aead,1) $(call AddDepends/crypto, +kmod-crypto-null) endef diff --git a/package/kernel/linux/modules/fs.mk b/package/kernel/linux/modules/fs.mk index 06c609b7540f..6732c7c73a18 100644 --- a/package/kernel/linux/modules/fs.mk +++ b/package/kernel/linux/modules/fs.mk @@ -98,13 +98,13 @@ define KernelPackage/fs-cifs AUTOLOAD:=$(call AutoLoad,30,cifs) $(call AddDepends/nls) DEPENDS+= \ -+(LINUX_5_4||LINUX_5_10):kmod-crypto-md4\ ++LINUX_5_10:kmod-crypto-md4\ +kmod-crypto-md5 \ +kmod-crypto-sha256 \ +kmod-crypto-sha512 \ +kmod-crypto-cmac \ +kmod-crypto-hmac \ -+(LINUX_5_4||LINUX_5_10):kmod-crypto-arc4 \ ++LINUX_5_10:kmod-crypto-arc4 \ +kmod-crypto-aead \ +kmod-crypto-ccm \ +kmod-crypto-ecb \ @@ -176,9 +176,7 @@ define KernelPackage/fs-exfat KCONFIG:= \ CONFIG_EXFAT_FS \ CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8" - FILES:= \ - $(LINUX_DIR)/drivers/staging/exfat/exfat.ko@lt5.7 \ - $(LINUX_DIR)/fs/exfat/exfat.ko@ge5.7 + FILES:= $(LINUX_DIR)/fs/exfat/exfat.ko AUTOLOAD:=$(call AutoLoad,30,exfat,1) DEPENDS:=+kmod-nls-base endef @@ -413,7 +411,7 @@ define KernelPackage/fs-nfs-common $(LINUX_DIR)/fs/lockd/lockd.ko \ $(LINUX_DIR)/net/sunrpc/sunrpc.ko \ $(LINUX_DIR)/fs/nfs_common/grace.ko \ - $(LINUX_DIR)/fs/nfs_common/nfs_ssc.ko@ge5.10 + $(LINUX_DIR)/fs/nfs_common/nfs_ssc.ko AUTOLOAD:=$(call AutoLoad,30,grace sunrpc lockd) endef diff --git a/package/kernel/linux/modules/i2c.mk b/package/kernel/linux/modules/i2c.mk index f4297632272a..15fd1ccddc42 100644 --- a/package/kernel/linux/modules/i2c.mk +++ b/package/kernel/linux/modules/i2c.mk @@ -90,7 +90,7 @@ I2C_DWCORE_MODULES:= \ define KernelPackage/i2c-designware-core $(call i2c_defaults,$(I2C_DWCORE_MODULES),58) TITLE:=Synopsys DesignWare I2C core - DEPENDS:=+kmod-i2c-core +!LINUX_5_4:kmod-regmap-core + DEPENDS:=+kmod-i2c-core +kmod-regmap-core HIDDEN:=y endef diff --git a/package/kernel/linux/modules/netdevices.mk b/package/kernel/linux/modules/netdevices.mk index 32cd0dcdcdb2..ff5284276cc8 100644 --- a/package/kernel/linux/modules/netdevices.mk +++ b/package/kernel/linux/modules/netdevices.mk @@ -141,7 +141,7 @@ $(eval $(call KernelPackage,mii)) define KernelPackage/mdio-devres SUBMENU:=$(NETWORK_DEVICES_MENU) TITLE:=Supports MDIO device registration - DEPENDS:=@(LINUX_5_10||LINUX_5_15) +kmod-libphy +(TARGET_armvirt||TARGET_bcm27xx_bcm2708||TARGET_tegra):kmod-of-mdio + DEPENDS:=+kmod-libphy +(TARGET_armvirt||TARGET_bcm27xx_bcm2708||TARGET_tegra):kmod-of-mdio KCONFIG:=CONFIG_MDIO_DEVRES HIDDEN:=1 FILES:=$(LINUX_DIR)/drivers/net/phy/mdio_devres.ko @@ -163,10 +163,8 @@ define KernelPackage/mdio-gpio CONFIG_MDIO_BITBANG \ CONFIG_MDIO_GPIO FILES:= \ - $(LINUX_DIR)/drivers/net/phy/mdio-gpio.ko@lt5.10 \ - $(LINUX_DIR)/drivers/net/phy/mdio-bitbang.ko@lt5.10 \ - $(LINUX_DIR)/drivers/net/mdio/mdio-gpio.ko@ge5.10 \ - $(LINUX_DIR)/drivers/net/mdio/mdio-bitbang.ko@ge5.10 + $(LINUX_DIR)/drivers/net/mdio/mdio-gpio.ko \ + $(LINUX_DIR)/drivers/net/mdio/mdio-bitbang.ko AUTOLOAD:=$(call AutoProbe,mdio-gpio) endef @@ -593,7 +591,7 @@ $(eval $(call KernelPackage,8139cp)) define KernelPackage/r8169 SUBMENU:=$(NETWORK_DEVICES_MENU) TITLE:=RealTek RTL-8169 PCI Gigabit Ethernet Adapter kernel support - DEPENDS:=@PCI_SUPPORT +kmod-mii +r8169-firmware +kmod-phy-realtek +(LINUX_5_10||LINUX_5_15):kmod-mdio-devres + DEPENDS:=@PCI_SUPPORT +kmod-mii +r8169-firmware +kmod-phy-realtek +kmod-mdio-devres KCONFIG:= \ CONFIG_R8169 \ CONFIG_R8169_NAPI=y \ @@ -719,7 +717,7 @@ $(eval $(call KernelPackage,igbvf)) define KernelPackage/ixgbe SUBMENU:=$(NETWORK_DEVICES_MENU) TITLE:=Intel(R) 82598/82599 PCI-Express 10
Re: [PATCH] bcm53xx: disable GRO support at kernel level
On 10.06.2022 15:16, Rafał Miłecki wrote: This improves NAT masquarade network performance. An alternative to kernel change would be runtime setup but that requires ethtool and identifying relevant network interface and all related switch ports interfaces. I sent another patch that should supersede this one: [PATCH] bcm53xx: disable GRO by default at kernel level https://patchwork.ozlabs.org/project/openwrt/patch/20220620082120.11714-1-zaj...@gmail.com/ It's probably a better idea to disable GRO *by default* (and allow re-enabling it). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
State of userland access to GPIO based hardware?
Hi all, I'm trying to bring my OpenWrt-based IoT targets from 19.07 to 22.03. In this process I got a bit confused about the state of userland access to GPIOs. I know that there is some ideology level discussion about userland GPIOs in general, and some strong opinions that these are not to be used for anything serious. As my target's very purpose is enabling the user to do things with GPIOs and software SPI/I2C from the application level, I can live with the verdict "not serious", but not without userland GPIOs ;-) In 19.07 there was: - /sys/class/gpio for accessing individual GPIOs - kmod-spi-gpio-custom, kmod-i2c-gpio-custom to create bit-banged SPI/I2C on GPIOs In 23.03: - /sys/class/gpio still exists, but is deprecated. Switching from explicit to automatic `base` in gpio_chip has changed the old-style datasheet aligned GPIO numbers to a very non-intuitive 512-gpiochipN*32 scheme (at least in my MT76x8 targets). The DT property `gpio-base` that was available in gpio-mt7621.c to set a custom base has been removed. - the new recommended access to GPIO from userland is now gpiod, however exists in a strange intermediate state where apparently the already deprecated v1 ABI needs to be enabled in the kernel (`CONFIG_GPIO_CDEV_V1`), because the "official" toolset for using gpiod from userland, libgpiod, has not been released yet in v2 that would support the current v2 ABI. - kmod-spi-gpio-custom and kmod-i2c-gpio-custom have been completely removed in "6362a04 - kernel: remove obsolete kernel version switches for 4.14". This puts targets like mine in a situation with workable access to GPIOs (choosing between strange numbered old-style and deprecated V1 API based new style), but without any way to establish spi/i2c on GPIOs any more. A elegant solution for using kmod-spi-gpio and similar (e.g. w1-gpio) drivers would have been device tree overlays loadable via configfs. Unfortunately, a patchset importing the needed configfs client has been rejected: http://lists.openwrt.org/pipermail/openwrt-devel/2021-November/037139.html. So my bottom line questions would be: - what is the envisioned future for GPIO userland access in OpenWrt in general? - in particular, how to use kmod-gpio-i2c/spi/w1 etc. in 22.03 without baking the GPIO assignments into a fixed DT? Best Regards, Lukas PS: of course I can (and currently do) patch all this such that it works for me, but my general goal is doing things as much as possible along the standard OpenWrt lines - which appear a bit blurred here, so that's why I ask. signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] bcm53xx: disable GRO by default at kernel level
From: Rafał Miłecki This improves NAT masquarade network performance. An alternative to kernel change would be runtime setup but that requires ethtool and identifying relevant network interface and all related switch ports interfaces. Signed-off-by: Rafał Miłecki --- .../600-net-disable-GRO-by-default.patch | 36 +++ 1 file changed, 36 insertions(+) create mode 100644 target/linux/bcm53xx/patches-5.10/600-net-disable-GRO-by-default.patch diff --git a/target/linux/bcm53xx/patches-5.10/600-net-disable-GRO-by-default.patch b/target/linux/bcm53xx/patches-5.10/600-net-disable-GRO-by-default.patch new file mode 100644 index 00..506e6f5b99 --- /dev/null +++ b/target/linux/bcm53xx/patches-5.10/600-net-disable-GRO-by-default.patch @@ -0,0 +1,36 @@ +From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= +Date: Mon, 20 Jun 2022 10:01:18 +0200 +Subject: [PATCH] net: disable GRO by default +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +In many cases GRO improves network performance however it comes at a +cost of chacksums calculations. In case of slow CPU and missing hardware +csum calculation support GRO can actually decrease network speed. + +On BCM4708 *disabling* GRO results in following NAT masquarade speed +changes: +1. 364 Mb/s → 396 Mb/s (packet steering disabled) +2. 341 Mb/s → 566 Mb/s (packet steering enabled) + +Signed-off-by: Rafał Miłecki +--- + include/linux/netdev_features.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/include/linux/netdev_features.h b/include/linux/netdev_features.h +@@ -231,10 +231,10 @@ static inline int find_next_netdev_feature(u64 feature, unsigned long start) + #define NETIF_F_UPPER_DISABLESNETIF_F_LRO + + /* changeable features with no special hardware requirements */ +-#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO) ++#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO) + + /* Changeable features with no special hardware requirements that defaults to off. */ +-#define NETIF_F_SOFT_FEATURES_OFF NETIF_F_GRO_FRAGLIST ++#define NETIF_F_SOFT_FEATURES_OFF (NETIF_F_GRO_FRAGLIST | NETIF_F_GRO) + + #define NETIF_F_VLAN_FEATURES (NETIF_F_HW_VLAN_CTAG_FILTER | \ +NETIF_F_HW_VLAN_CTAG_RX | \ -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
