[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <trinity-6ad483d2-5c50-4f38-b386-f4941c85c1fd-1677413524438@3c-app-gmx-bs15>
Date: Sun, 26 Feb 2023 13:12:04 +0100
From: Frank Wunderlich <frank-w@...lic-files.de>
To: Arınç ÜNAL <arinc.unal@...nc9.com>,
Felix Fietkau <nbd@....name>
Cc: Vladimir Oltean <olteanv@...il.com>,
netdev <netdev@...r.kernel.org>, erkin.bozoglu@...ont.com,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
John Crispin <john@...ozen.org>,
Mark Lee <Mark-MC.Lee@...iatek.com>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Landen Chao <Landen.Chao@...iatek.com>,
Sean Wang <sean.wang@...iatek.com>,
DENG Qingfang <dqfext@...il.com>
Subject: Aw: Re: Re: Choose a default DSA CPU port
Hi,
> Gesendet: Samstag, 25. Februar 2023 um 20:56 Uhr
> Von: "Arınç ÜNAL" <arinc.unal@...nc9.com>
> On 25.02.2023 19:11, Arınç ÜNAL wrote:
> > On 25.02.2023 16:50, Frank Wunderlich wrote:
> >> f63959c7eec3151c30a2ee0d351827b62e742dcb is the first bad commit
> >
> > Thanks a lot for finding this. I can confirm reverting this fixes the
> > low throughput on my Bananapi BPI-R2 as well.
> Just tested on an MT7621 Unielec U7621-06 board. MT7621 is not affected.
do you have full 1G (940 Mbit/s) on mt7621 device in 6.1??
if you look at the commit you see a special handling for mt7621
if (IS_ENABLED(CONFIG_SOC_MT7621)) {
...
}else{
//all others go there including mt7623, out (t)rgmii should be here (internally SPEED_100 afair, but higher clock for trgmii):
case SPEED_1000:
val |= MTK_QTX_SCH_MAX_RATE_EN |
FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 10) |
FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 5) |
FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 10);
break;
}
but i do not understand the full code as it looks like it changes the full packet-handling ;)
imho reverting is good for test, but dropping the full change is not the right way...we should wait for felix here
but back to topic...we have a patch from vladuimir which allows setting the preferred cpu-port...how do we handle mt7531 here correctly (which still sets port5 if defined and then break)?
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/drivers/net/dsa/mt7530.c#n2383
/* BPDU to CPU port */
dsa_switch_for_each_cpu_port(cpu_dp, ds) {
mt7530_rmw(priv, MT7531_CFC, MT7531_CPU_PMAP_MASK,
BIT(cpu_dp->index));
break; //<<< should we drop this break only to set all "cpu-bits"? what happens then (flooding both ports with packets?)
}
as dsa only handles only 1 cpu-port we want the real cpu-port (preferred | first). is this bit set also if the master is changed with your follow-up patch?
regards Frank
Powered by blists - more mailing lists