lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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