The mtu values i provided earlier are the max values each interface supports (Excluding br-lan and wwan0) I noticed that i forgot to include eth2 (it also uses 2022 which is why i set br-lan to that)
But again i’m using 1500 now on all interfaces since changing the MTU causes the issues i described earlier to happen.
Hi @frank-w newbie question here, I flashed the old OpenWRT image on a SD-Card. Does [wed_task0] and [wed_task1] and mtk_ppe_dev_register_hook mean WED is working ?
5715 2 root DW 0 0% 0% [wed_task1]
5711 2 root DW 0 0% 0% [wed_task0]
9116 2 root SW 0 0% 0% [ksmbd-br-lan]
9228 2 root SW 0 0% 0% [RtmpMlmeTask_02]
8247 2 root SW 0 0% 0% [BPCCCmdQTask_01]
root@OpenWrt:~# dmesg | grep -i "wed\|offload\|ppe\|dispatch\|mtk_wed"
[ 48.584720] [email protected],tid_map_sanity() 1743: [0] unmapped_tid(0x0)
[ 48.926307] mtk_ppe_dev_register_hook : ineterface ra0 register (1)
[ 49.593554] mtk_soc_eth 15100000.ethernet eth0: TX vlan offload cannot be enabled when dsa is attached.
[ 50.222742] mtk_ppe_dev_register_hook : ineterface apcli0 register (2)
[ 50.428217] mtk_ppe_dev_unregister_hook : ineterface apcli0 set null (2)
[ 52.024773] [email protected],tid_map_sanity() 1743: [1] unmapped_tid(0x0)
[ 52.291561] mtk_ppe_dev_register_hook : ineterface rai0 register (2)
[ 53.714438] mtk_ppe_dev_register_hook : ineterface apclii0 register (3)
[ 54.012249] mtk_ppe_dev_unregister_hook : ineterface apclii0 set null (3)
[ 55.838616] [email protected],tid_map_sanity() 1743: [2] unmapped_tid(0x0)
[ 56.120941] mtk_ppe_dev_register_hook : ineterface rax0 register (3)
[ 56.984896] mtk_ppe_dev_register_hook : ineterface apclix0 register (4)
[ 57.212400] mtk_ppe_dev_unregister_hook : ineterface apclix0 set null (4)
root@OpenWrt:~# uname -a
Linux OpenWrt 5.4.271 #0 SMP Wed Jun 5 06:11:29 2024 aarch64 GNU/Linux
Wonder about r4pro image with kernel 5.4,thought it was 6.6.
No idea about wed as i had not done much tests with it…
Yes i’ve seen it already 
but thanks for the ping.
But it looks like muxing itself is not yet part of this series yet.
Fair enough Frank, I was delightfully surprised these were active already myself. Hopefully they hurry up and update the wirelessreg.db / regulatory.db to reflect the ratified 6Ghz channels because It is still not updated from last year.
root@OpenWrt:~# dmesg | egrep -i 'dma|dma_mask|set DMA|DMA mask'
[ 7400.929895] warp_dev2 15010000.wed: Using 36bit DMA for streaming map
[ 7400.936328] warp_dev2 15010000.wed: Using 32bit DMA for coherent map
[ 7401.146797] warp_dev3 15010000.wed2: Using 36bit DMA for streaming map
[ 7401.153316] warp_dev3 15010000.wed2: Using 32bit DMA for coherent map
[ 7396.854516] wdma_dma_ctrl(): WDMA_GLO_CFG0=be275, txrx = 0
...
[ 7401.513063] wdma_dma_ctrl(): WDMA_GLO_CFG0=be27c, txrx = 3
root@OpenWrt:~# cat /proc/interrupts
129: 0 0 0 0 INTx 0 Edge -INTx mt7990-vec_data0
130: 0 0 0 0 INTx 0 Edge -INTx mt7991-vec_data0
root@OpenWrt:~# lsmod | grep -E "offload|flow"
nf_flow_table_hw 16384 1
root@OpenWrt:~# iptables -t filter -L FORWARD -v -n
...
23 1408 FLOWOFFLOAD all -- * * 0.0.0.0/0 0.0.0.0/0 /* !fw3: Traffic offloading */ ctstate RELATED,ESTABLISHED FLOWOFFLOAD hw
root@OpenWrt:~# cat /proc/net/nf_conntrack | head -20
...
ipv4 2 tcp 6 src=192.168.1.156 dst=157.240.8.52 sport=64556 dport=443 ... [OFFLOAD] ...
...
ipv4 2 tcp 6 src=192.168.1.156 dst=157.240.8.1 sport=51658 dport=443 ... [OFFLOAD] ...
root@OpenWrt:~# ethtool -k eth0
rx-checksumming: on
tx-checksumming: on
...
scatter-gather: on
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
Where should it be updated? I do not update older posts when such information changes. My wiki should be up2date for this. But i remember that something took more time to be 4gb ready (afair ppe)
Good catch edited that out. Speaking of , do you have any examples of even better hardware offloading performance ? 
Those were enabled out of the box maybe I could achive even better with good documentation.
If I recall correctly, PPE was fixed to work with 4 GB RAM by adding support for 36-bit addressing. WED was fixed later. I could be wrong though.
Nice do you know if WED works on other distros ? I didn’t even know I could run other distros on banana pi that work around the Mediatek MT7996 WIFi7 development issues.
[][kerne/kernel-6.6/kernel-6.12][mt7988][eth][Update AN8831X 10G PHY driver to 1.9.2]
[Description] Update AN8831X 10G PHY driver to 1.9.2.
Changes from Firmware Version 1.9.1:
[Release-log] N/A
does this only apply to the R4 Pro? or also to the non-pro? I have a R4 and wondering if i could simply replace the .bin
Hi oli, the r4 doesn’t have the aeonsemi 10g phy. this is r4-pro specific as the entire thread is.
Yeah,but sdk changed to an larger driver with debug parts. So not upstreamable and i found no time yet to analyse differences in core. For upstream openwrt and mainline linux we have to first get ethmux (phy port series from maxime as base) complete.
I haven’t checked. You’ll probably be using frank-w’s kernels in that case so feel free to check the commit log for the WED patches.
I use mine as a wired router, which is also what I recommend to others, so I simply haven’t cared enough about WED to check what patches are needed for that feature.
This looks good. Maybe I should contact BPI and ask if they can add this patch.
Hi everyone!
I don’t want to spam the PR comments on GitHub, but could you please share with the community and everyone waiting what stage this PR is currently at? Are there any specific issues or blockers you’ve run into, and is it expected that the WIP/draft label might be removed in the near future?
We really appreciate all the work you’re doing on the mainline branch and are keeping our fingers crossed
Don’t expect that to be merged and hence have mainline openwrt support earlier than June.
There are critical missing parts in the Linux kernel that will take time to be developed and than back ported. So take a seat an stick with the sinovoip or mediatek code/builds
Hello, Back again.
Just put my entire home lab through extensive testing and i’m happy to see the bpi r4 pro maxing out it’s internal inband USXGMII 10 gigabit connection without exploding.
However…
This is only through the maxlinear switch.
If i connect my PC to the 10 gigabit rj45 port then run a simple iperf3 test the bpi completely craps out and only does a few megabits/s if any
That can be “fixed” by setting scatter gather off on eth2, Then the bpi can do up to a gigabit of TX throughput and link speed RX (In my case my pc has a 5 gigabit port so 5 gigabit)
That sadly has the downside of completely nuking any high bandwidth traffic on the maxlinear switch
Any ideas?
I wanna put the blame on the fact my PC has a 5 gigabit port and the 10 gigabit port on the bpi is running at an unsupported/unadvertised speed, Could be wrong though, Lmk
It would be better creating a new topic with telling you used image (bpi,openwrt with/without sdk,…) and exact port…
There are known issues with the phy chip (rj45 port on both combo). Lan combo is behind mxl switch,wan combo directly on mtk mac.
Specific question in this general thread leading to confusion.