Modify MTK_PPE_ENTRIES_SHIFT on mtk_ppe.h
4 = 16k
5 = 32k
1 Like
Would it break compatibility for other mtk devices? I'm not sure if all mtk devices support such large entry table.
appreciate if you churn out a simple patch to update it from 8K to 32K.
thanks a millon.
From 06748d507c7b2b431761f21dd71b4ec4f7841c90 Mon Sep 17 00:00:00 2001
From: Elad Yifee <eladwf@gmail.com>
Date: Sun, 16 Jun 2024 16:26:48 +0300
Subject: [PATCH] change ppe entries num to 32K
Signed-off-by: Elad Yifee <eladwf@gmail.com>
---
drivers/net/ethernet/mediatek/mtk_ppe.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.h b/drivers/net/ethernet/mediatek/mtk_ppe.h
index 691806bca372..6db85d897fa9 100644
--- a/drivers/net/ethernet/mediatek/mtk_ppe.h
+++ b/drivers/net/ethernet/mediatek/mtk_ppe.h
@@ -8,7 +8,7 @@
#include <linux/bitfield.h>
#include <linux/rhashtable.h>
-#define MTK_PPE_ENTRIES_SHIFT 3
+#define MTK_PPE_ENTRIES_SHIFT 5
#define MTK_PPE_ENTRIES (1024 << MTK_PPE_ENTRIES_SHIFT)
#define MTK_PPE_HASH_MASK (MTK_PPE_ENTRIES - 1)
#define MTK_PPE_WAIT_TIMEOUT_US 1000000
--
2.45.1
there you go!
i'm not sure about older NETSYS devices, I need to check
2 Likes
Many thanks
Seems MT7986 also supports 32k entries according to datasheet, also MT7981 supports that. But I didn't find earlier chips' maximum entries info.
Not anymore it's not. It appears to cause problems when WED is used, I need to come up with a solution. It's dropped for now
Wifi7 cards status can be found here: [Banana BPI-R4] Wifi7 status
2 Likes
Sorry for out of topic but i wish to know if someone is using MT7916AN too... I have an issue with heating... Idle state is 63C but if some high download the temp is increased up to 85C. . Is it normal?
Temp of the cards was an issue as I had them in a printed case.
Since transfer to the BPi metal case and using thermal pads that are connected to the case the temperature is "ok" (see screenshot).
Good to know / tip to keep temps lower:
I've used the top cover of one of my printed cases for the official BPi case because it had holes for the active CPU/RAM fan that came with the acrylic case.
In the printed and acrylic cases the 7916 was between 60 to 85 degrees celsius.
1 Like
From your OpenSSL numbers, I could guess you're compiling with -O3. 
OpenSSL's assembly codes use crypto extension if available. So 'openssl speed' ends up benchmarking ARM cores' crypto extension (and core frequencies).
The sad news is that commonly available SoCs from the same era seem to come with same set of crypto extension regardless of little or big cores. Hence, it ends up benchmarking the core frequencies...solely.
I got the impression you seem to know what you were doing.
In the past week, I had reinstalled/upgraded OpenWrt enough number of times. Not sad but that was the intention. Read up some setups people do. So far I've come up with how to run my R4 with OpenWrt:
-
Run a minimal installation of OpenWrt. Might have to build my own kernel. This will run R4 as a router.
-
Use OpenWrt's LXC package to run and manage three containers: one for internet facing services, one for LAN facing services (non core router functions), one for my interactive shells and ongoing experiments.
-
Each container will run the same installation of ArchLinux for ARM. I decided not to run OpenWrt packages inside the containers.
-
Containers will install on Extroot and hence persistent across OpenWrt upgrades. But I want OpenWrt, the three containers (and the copy of ArchLinux for ARM installation + application data) reside in the same 8GB eMMC. Will partition the 8GB eMMC into 500MB for OpenWrt, and 7.5GB for Extroot but haven't looked into details if possible or desirable.
Any critics? Suggestions? Alternative & better practices? Soliciting feedback from anyone who's doing something similar.
i use bpi-r4 as a wired router so wed does not affect me.
Will have to stay with the build before daniel reverted the multiple ppe patch thou.
1 Like
Thanks, your testing is appreciated 
anyone running irqbalance in your bpi-r4 builds?
I tested with and without. Not much difference I can detect since I am not running anything intensive.
Only change i notice when enabled is that these two get moved. they stay on cpu0 when irqbalance is not enabled,
CPU0 CPU1 CPU2 CPU3
104: 1219 899090 0 0 GICv3 229 Level 15100000.ethernet
105: 1524 0 0 1426740 GICv3 230 Level 15100000.ethernet
I reverted these two commits to stay in-sync with openwrt maintree but still keeping multple ppe enabled
1 Like
I spotted, that by enabling irqbalance, there was no performance improvement, so I disable it.
The packet_steering seems to make a diff in the tests (in positive meaning).
Does someone use the BPI-R4 as main router and got another AP as dumb_ap and got some connectivity issues recently (I spotted that it started since kernel 6.6.33)?
packet_steering makes a diff? How so?
since packet forwaridng is already offloaded by ppe. what positive difference are you seeing?
I run bpi-r4 as a wired main router and have dump APs connected. some of these dumb APs also have vlans on them. I have not noticed any issue since the move to 6.6.33. What issues are you facing?
1 Like
For the packet steering: I have done many iperf3/speedtest/bufferbloat and it gives me best results when its enabled. Of course the results also depends of my ISP traffic and remote server as well.
For the dumb_ap (ax3200): it is like the connection to the dump_ap is dropped when there is some bigger traffic. There is nothing in the dmesg/logread - connection is estabilished, no disconnect/connect back. It is just the clients wants to reach the Internet and they nees to wait a few second or click many times to get the content (which mostly is not loaded coreectly).
If nobody have any issue, I will create an immage with last Dango changes and let's see.