@shm0
Do you have a patch? I would like to test this.
Here:
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -703,8 +703,8 @@ static enum cpuhp_state online_hpstate;
/* The hardware supports eight (8) rx queues, but we are only allowing
* the first one to be used. Therefore, let's just allocate one queue.
*/
-static int rxq_number = 8;
-static int txq_number = 8;
+static int rxq_number = 2;
+static int txq_number = 2;
static int rxq_def;
@@ -1471,7 +1471,7 @@ static void mvneta_defaults_set(struct m
*/
if (txq_number == 1)
txq_map = (cpu == pp->rxq_def) ?
- MVNETA_CPU_TXQ_ACCESS(1) : 0;
+ MVNETA_CPU_TXQ_ACCESS(0) : 0;
} else {
txq_map = MVNETA_CPU_TXQ_ACCESS_ALL_MASK;
@@ -4165,7 +4165,7 @@ static void mvneta_percpu_elect(struct m
*/
if (txq_number == 1)
txq_map = (cpu == elected_cpu) ?
- MVNETA_CPU_TXQ_ACCESS(1) : 0;
+ MVNETA_CPU_TXQ_ACCESS(0) : 0;
else
txq_map = mvreg_read(pp, MVNETA_CPU_MAP(cpu)) &
MVNETA_CPU_TXQ_ACCESS_ALL_MASK;
@@ -4923,9 +4923,6 @@ static const struct net_device_ops mvnet
.ndo_fix_features = mvneta_fix_features,
.ndo_get_stats64 = mvneta_get_stats64,
.ndo_do_ioctl = mvneta_ioctl,
-#ifndef CONFIG_ARM64
- .ndo_select_queue = mvneta_select_queue,
-#endif
.ndo_bpf = mvneta_xdp,
.ndo_xdp_xmit = mvneta_xdp_xmit,
};
This is the version with 1 RX/TX per CPU.
You can change the number of queues at the top.
1 TX queue should work now.
This also reverts the 700-mvneta-tx-queue-workaround.patch
Maybe I will rework this to automatically set queues = max_cpus.
The 1 RX queue on CPU0 and 1 TX queue on CPU1 needs some hard coding of the CPUs.
I didn't find a neat way to make this work.
To only use RSS disable packet steering in /etc/config/network.
XPS should be automatically setup.
To switch to basic qdisc put this into rc.local:
tc qdisc replace dev eth0 root handle 1: mq
tc qdisc replace dev eth0 parent 1:1 handle 110 pfifo
tc qdisc replace dev eth0 parent 1:2 handle 120 pfifo
Here are some other patches which may improve perfomance:
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -113,10 +113,13 @@
reg = <0x8000 0x1000>;
cache-unified;
cache-level = <2>;
- arm,double-linefill-incr = <0>;
- arm,double-linefill-wrap = <0>;
- arm,double-linefill = <0>;
- prefetch-data = <1>;
+ prefetch-instr = <1>;
+ prefetch-data = <1>;
+ arm,double-linefill = <1>;
+ arm,double-linefill-incr = <1>;
+ arm,double-linefill-wrap = <1>;
+ arm,prefetch-drop = <1>;
+ arm,prefetch-offset = <7>;
};
scu@c000 {
This reenables the double-linefill feature which was disabled because of stability reasons.
There is an errata for pl310 cache controller but this should be fixed in the armada devices as they use the latest revision.
I guess the instability was causes by something else and disabling the double-linefill just masqueraded the other issue(s).
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -41,8 +41,6 @@ config MACH_ARMADA_375
bool "Marvell Armada 375 boards"
depends on ARCH_MULTI_V7
select ARMADA_370_XP_IRQ
- select ARM_ERRATA_720789
- select PL310_ERRATA_753970
select ARM_GIC
select ARMADA_375_CLK
select HAVE_ARM_SCU
@@ -56,11 +54,7 @@ config MACH_ARMADA_375
config MACH_ARMADA_38X
bool "Marvell Armada 380/385 boards"
depends on ARCH_MULTI_V7
- select ARM_ERRATA_720789
- select PL310_ERRATA_753970
select ARM_GIC
- select ARM_GLOBAL_TIMER
- select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
select ARMADA_370_XP_IRQ
select ARMADA_38X_CLK
select HAVE_ARM_SCU
This disables all default erratas as they shouldn't be necessary on the armada devices because the use the newest hardware revision.
There is only one errata that is maybe of interest but I'm not sure if this even works from the kernel.
I think this needs to be applied at uboot level.
This also reverts the the clocksource back to the marvell provided one. (disabling ARM Global Timer)
As I found reports of users on a different forum noticing clock drift and bad WiFI performance.
The config symbols need to be manually removed from the kernel config.
All patches go into target/linux/mvebu/patches-5.10
2 Likes
Thanks for the info and patches. I will test them when I have time.
With the builds.. I'm running wrt1900acs version 2. (Shelby)
Which firmware do I use.. ?
I assume wrt1900acs one as there isn't one specific for version 2 of the 1900 acs though Linksys carry there own firmware's seperatly..
For the life of me I cannot get the Wan working with pppoe.. with the latest build. (04 August)
Upgraded from wrt1200ac (which will become a repeater).. running Dave snapshot..So quiet savvy already..
Fresh build, installed 'out of the box'. pppoe Username and password applied, yada yada, etc etc. Just fails to connect..
Left over night, to see if it's an ISP issue...still nothing
Plug BT modern straight into the old router, same settings.. no issue
Any chance these can be wrapped into a .patch file to import as part of building from master?
With 21.02 going stable and Master switching over to kernel 5.10, I know it doesn't effect these builds much but it's a very interesting week for this target. 
Care to elucidate with any prognostications?
Kia Ora,
Novice question - what does all this mean?
Are you stating that you have CPU0 for receiving and CPU1 for transmitting using a DSA config? So throughput is not impacted (or less impacted) vs the 'official' builds?
My main reason for staying on 19.x is my speeds reduce due to DSA.
Are there any other caveats or constraints before I go jumping in?
What about VLANs?
What speed reduce do you see with DSA?
It's been about 5months since I last played w/ DSA on my WRT1900ACSv2, however I was seeing about a 200mb drop on ingress - my connection is 950/500 fibre to the house.
People may say, "So what? At that speed..." but to me things also 'felt' a bit laggy across my entire network (3 wired PCs, AndroidTV, a couple NAS, and half a dozen wifi devices) but I am not smart enough to quantify this.
I am really hanging out for DSA multi-CPU support but not holding my breathe for a quick resolution as the solution has been in debate for a few years now based on what I have read.
I experience the same as you have described since moving to DSA. I've got 910/110 FTTH and there is a speed reduction compared to swconfig used in 19.07.
A good article exists which explains that the kernel doesn't support multiple CPU at the moment due to current attempts not being accepted upstream.
I haven't been able to find a patch that enables multi CPU for 5.10
Would this one not be of help?
Seems they managed to get multi-cpu working with DSA with a few other patches following that commit
I have seen this but don't think it is designed for this target (mvebu).
@Ansuel will this work for mvebu?
It's generic to the kernel itself, i.e., it is not architecture specific other than how many CPU's you have. Mostly the patches allow one to manually configure which CPU will be assigned to process data from a specific switch port. The default is for one CPU to process all the ports.
So the above pull request is target specific…
I also mentioned a few posts ago the comments you made regarding the kernel and the fact that DSA uses 1 cpu port by default.
Not the way it reads to me.
Okay. What architecture are the patches limited to?
I took comment in post to mean it was applicable to other targets; that being bits indicated by the comment. I have not bothered to kick it around myself as the pipe to my shack is far from a symmetric pipe that would warrant the need on the wrtpac targets.
2 Likes
My bad - ipq806x, ar71xx, ath79.
Misconstrued the context.
I too read it this way.
I see our benefactor has created a new build on 15 Sept which I want to test if multi CPU is working before I roll my own (I use this as a base and add a couple pkg).
What is an easy way to see CPU use by CPU? "top" only shows total percentage and the other top commands to breakdown by proc don't work.
