OpenWrt 22.03.0-rc4 fourth release candidate
Hi, The OpenWrt community is proud to announce the fourth release candidate of the upcoming OpenWrt 22.03 stable version series. It incorporates over 3500 commits since branching the previous OpenWrt 21.02 release and has been under development for about one year. This is just a release candidate and not the final release yet. Download firmware images directly from our download servers: * https://downloads.openwrt.org/releases/22.03.0-rc4/ OpenWrt 22.03.0-rc2 was skipped because the URL of the release repository was not updated correctly. OpenWrt 22.03.0-rc3 was skipped because of a severe problem in firewall4. Changes between OpenWrt 22.03.0-rc1 and 22.03.0-rc4 === Software updates * Linux kernel updated to version 5.10.120 (from 5.4.111 in v22.03.0-rc1) * wolfssl Update to version 5.3.0 (from 5.2.0 in v22.03.0-rc1) * openssl Update to version 1.1.1o (from 1.1.1n in v22.03.0-rc1) Misc changes * ucode: many updates * firewall4: many updates * Multiple fixes for flow offload fixing problems with IPv6 and PPPoE Device support * New devices * ath79: TP-Link Deco M4R * ath79: Netgear WNDAP360 * ath79: MikroTik RouterBOARD 952Ui-5ac2nD (hAP ac lite) * ath79: MikroTik RouterBOARD 951Ui-2nD (hAP) * ath79: Ubiquiti NanoBeam M5 * bcm53xx: Asus RT-AC88U * ipq806x: Arris TR4400 v2 * ramips: YunCore AX820 * ramips: TP-Link RE650 v2 * ramips: Wavlink WL-WN533A8 * ramips: SERCOMM NA502S * ramips: Cudy X6 * realtek: ZyXEL GS1900-16 * realtek: ZyXEL GS1900-24E * lantiq: Add upstream vectoring support Many other changes in all parts of OpenWrt, see Chnagelog for details. - Full release notes and upgrade instructions are available at https://openwrt.org/releases/22.03/notes-22.03.0-rc4 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/22.03/notes-22.03.0-rc4#known_issues For a detailed list of all changes since 22.03-rc1, refer to https://openwrt.org/releases/22.03/changelog-22.03.0-rc4 To download the 22.03.0-rc4 images, navigate to: https://downloads.openwrt.org/releases/22.03.0-rc4/ As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Have fun! The OpenWrt Community --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Fwd: Testing network / NAT performance
[Ugh, now with less HTML, sorry about that…] Hi, Rafał, On Tue, 14 Jun 2022 at 14:20, Rafał Miłecki wrote: > > As you can see 4e0c54bc5bc8 has accidentally moved -fno-reorder-blocks > from !CONFIG_CC_OPTIMIZE_FOR_SIZE to CONFIG_CC_OPTIMIZE_FOR_SIZE. > > 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... Why not just drop both fno-reorder-blocks and -fno-tree-ch? I have no idea about the details, but those options seem to have been carried forward from a time where GCC probably had issues with them (code bloat, maybe). I've been carrying a patch in my tree for (about three) years, dropping both options, with no issues at all in all architectures (ARM1176JZF-S, 24Kc, 74Kc, 1004Kc, Cortex-A9, Cortex-A53, x86-64) and GCC versions (8, 9, 10, 11, 12) I've tested. Cheers, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Testing network / NAT performance
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.
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...
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
